Comments on: java.net.URL or java.net.URI?

By: Anonymous

Anonymous — Fri, 30 Mar 2007 22:20:40 +0000

Never. However, the only reason I’ve compared URLs before is for really primitive caching, and the URLs would have been constructed from the exact same String. Getting an unexpected false wouldn’t matter either. So while I’ve done an awful lot with HTTP, my usage of URLs has really just been a storage container - it could have been a String for all I really cared (and in many cases, it was a String).

By: Asbjørn Ulsberg

Asbjørn Ulsberg — Fri, 30 Mar 2007 13:49:18 +0000

Sounds like a smart pick and plan to me. When you say you’ve worked successfully with the URL class for at least 5 years, have you in any of those 5 years done url1.equals(url2) and not had unexpected results?

By: Adrian Sutton

Adrian Sutton — Fri, 30 Mar 2007 08:29:53 +0000

Well, I’ve been successfully working with the URL class for at least the past 5 years - as much as anything out of necessity because that’s what everything tends to use. All I really need in this case is an identifier - some other code will have to deal with retrieving resources, I just need a unique name to assign them so that they can be stored and retrieved in the cache, given the design of HTTP the obvious answer is a URL/URI. It is likely to be more useful for clients of the API to use URLs but it is easier to convert URLs to URIs than visa versa and given the advice that the URL class is so broken I’ve gone with java.net.URI. No doubt I’ll need to add utility methods that take URLs and convert them to URIs at some point, but this will let me keep moving forward and see if this becomes a worthwhile project or not.

By: Asbjørn Ulsberg

Asbjørn Ulsberg — Fri, 30 Mar 2007 08:10:02 +0000

What are you going to do with the URIs/URLs in your application? If you’re going to resolve them and have to rely on the URL class itself to do that, then that might make sense in a very obscure way. However, I think that’s just as wrong as having readFile() and writeFile() methods on the String class. It just doesn’t belong there, and if it was there, the class would be badly designed and imho broken. Thus, the URL class is broken.

If what you want is a generic class to represent the URI syntax with convenient methods to handle this syntax (e.g. extract portions of the URI for further inspection etc.), and leave resolving to a class better equipped to do it, then URI is definately the way to go. As Tim Bray writes, don’t go near the URL class, at least not unless you have explicit, well-thought and very sound reasons to do it.

By: Adrian Sutton

Adrian Sutton — Thu, 29 Mar 2007 22:18:47 +0000

Ok, so out of all of that I think my understanding was fairly right, if uncertain. URLs are a specific type of URI, every URL should be a valid URI and Java just screws it all up. Fair enough.

From a practical standpoint though I’m still in two minds - java.net.URL may be horribly broken, but it is what everyone uses. It seems unlikely that a HTTP caching algorithm would be useful for things that aren’t identified by URLs (exactly how do I send a HTTP request for urn:isbn:xxxx-xxxx-xxxx?) so I probably should just use them. I can always add a URI interface as well later if it ever proves useful.

By: David Venz

David Venz — Thu, 29 Mar 2007 20:30:28 +0000

The above comments are probably of more immediate use, but as another data-point:
Have you read RFC 3305, in particular section 2?

Cheers,
-Dave.

By: James Snell

James Snell — Thu, 29 Mar 2007 14:46:39 +0000

As Tim and Steve point out, java.net.URL is evil. java.net.URI is not a whole lot better but it’s still the best choice.

By: Steve Loughran

Steve Loughran — Thu, 29 Mar 2007 12:59:33 +0000

Do not go near java.net.URL if you can help it. In some recently fixed releases of Java, it would hang the thread in the Constructor until a reverse DNS lookup of the proxy server timed out.

By: Tim Bray

Tim Bray — Thu, 29 Mar 2007 12:32:08 +0000

I’d say URI is the only sane choice. See http://www.tbray.org/ongoing/When/200x/2003/02/27/URL and http://www.w3.org/TR/webarch and for a nasty surprise, check out the sickening broken-ness of java.net.URL.equals()