Given that this is Google, they had to take things to that next level. And by that, I of course mean that their implementation has a few twists and refinements so brilliant and elegant that they seem obvious in retrospect and make the rest of us feel unworthy. Because we are.

The aspect of ImageBundle that jumps out at me is the infinite cacheability of the images: the file name includes an MD5 of the image contents, so there is no need for even periodic HTTP round trips for if-modified-since or if-none-match checks. You can set the expiration date to the expected heat death of the universe, or beyond. Thus, network requests are only made when they are absolutely necessary. Only one network round trip is made at that time. Everything is as simple as possible, but not one bit simpler.

And to those naysayers who may suggest a pathological case where minor modifications to one or two contained images cause frequent downloads of the larger, concatenated image: it just doesn’t matter. As this post at edgeblog explores, it’s still the latency, stupid. The real cost of object downloads is the round tripping. Establishing a connection, sending a request, and waiting for the first byte dominate network times. The added marginal cost of additional contents is always a fraction of those setup costs as the bytes of the reply are in flight by the time you begin receiving the reply. And as bandwidth increases while latency remains relatively flat, the dominance of latency will only increase.

As implemented, hashCode uses the IP address of the URL hostname as part of its calculations. This leads to at least three annoying issues:

1. Calling equals on a URL or using it as a key to a Map is a blocking operation on a network call. It’s unlikely this is what you intended, but it’s easy enough to overlook until (e.g.) your primary name server dies and you wonder why all hash lookups are now taking 5 seconds. This is how I stumbled onto the issue years ago.
2. Calling equals on two URLs with identical paths and different hostnames will return true in the case that both hostnames map to the same IP. It can certainly be argued that this is intended behavior since the URLs point to the same network resource, but I’m guessing that most developers who call myURL.equals(yourURL) are expecting to get a string comparison, ala myURL.toString().equals(yourURL.toString())
3. Using a URL as a key into a Map may lead to a miss in a DNS round robin scenario where the same hostname maps to multiple IPs. This is, I think, the most insidious case as most URLs will hash properly until one day you discover multiple entries in a Map keyed to string-identical URLs.

My advice? Simple enough. Just use strings. When working on projects involving URLs, a useful internal convention is to use all capitals to designate a method that will return a URL and lower case for a method that will return a String representation of the URL, perhaps suffixing with String just to be absolutely clear. Example:

public interface HttpRequest {
   public URL getURL();
   public String getUrlString();
}

Also, generic collections make spotting abuse of this convention much easier in the Map cases. Code that does HashMap<URL, HttpRequest> has a very distinct odor and is much easier to sniff out at the source.