4 ms·
I recently had a wild ride with using java.net.URL and java.net.URI, to parse and deconstruct URIs so they can be stored in a database with at least a little no
by afandian 3y ago
I recently had a wild ride with using java.net.URL and java.net.URI, to parse and deconstruct URIs so they can be stored in a database with at least a little normalization.
The documentation page is great but the API is bizarre. So many different constructors with different permutations of whether or not they expect various segments to be URL-encoded.
If nothing else, the complexity convinced me not to write my own!
- https://docs.oracle.com/javase/8/docs/api/java/net/URI.html https://docs.oracle.com/javase/8/docs/api/java/net/URI.html
- https://docs.oracle.com/javase/8/docs/api/java/net/URL.html https://docs.oracle.com/javase/8/docs/api/java/net/URL.html
- ivan_gammel 3y agoIt is worth mentioning that Java started supporting URIs even before RFC 2396 became a standard. And then RFC 3986 came and made incompatible changes, e.g. by moving asterisk to reserved characters (I could not find an explanation why in W3C email archive - someone asked this question at the draft stage, but it was not answered there).
- jeroenhd 3y agoOne 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.
- yjftsjthsd-h 3y agoSo 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
- ivan_gammel 3y agoThat's an ancient API that is de facto deprecated by best practices. Java 1.0 was far from perfect regarding the design decisions.
- vips7L 3y agoFrom the docs: > The java.net.URL constructors are deprecated. Developers are encouraged to use java.net.URI to parse or construct a URL.
- afandian 3y agoExcept it accepts some inputs that URI balks at. I don't recall the exact case, but when I was trying to toleratly parse a URI, I fall back a URL and then convert it to a URI.
- vips7L 3y agojava.net.URL is deprecated. It’s a mistake from the 90s.
- paulddraper 3y agoIt is beyond surprising, it is horrifying. Also, URI not URL has been the preferred choice for years and years and years. But the footgun persists, for backwards compatibility
- ivan_gammel 3y agoIt 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().
- afandian 3y agoIt's up there with "java.text.SimpleDateFormat is not threadsafe". SONAR catches that at least.
- usrusr 3y agoLearned, 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.
- ryukoposting 3y agoThat description reads like an xkcd comic.
- EdwardDiego 3y agoYeah, a golden rule of Java dev is don't use URL. Use URI instead. URL is one of those "it seemed like a good idea in the 90s" legacy warts.