Hacker News Reader

Comment by deepsun | Hacker News Reader

I actually like it. I also create my own exceptions for rare (exceptional) cases, just not to forget to handle them.

But some Java SDK exceptions drive me crazy. For example `URL.parse("http://example.com")` over hard-coded strings that I know 100% won't throw exceptions, but I still to catch 3 of them.

View on HN

That's why URI has a factory method that you're only supposed to use for known strings (although of course this can't be checked):

https://docs.oracle.com/javase/7/docs/api/java/net/URI.html#...

After URI appeared in 1.4, the only reason to use URL was to create a URLConnection from a URI. Since openConnection() throws IOException, it's not a big deal that toURL() throws a MalformedURLException - just catch it along with all the other IOExceptions.

Since 11, there's no reason to use URL at all, because you can use HttpClient to actually do HTTP.

Ok I'm a veteran Java developer that understands exactly what you're saying but try explaining that to people unfamiliar with Java or junior engineers and watch their brains glaze over.

The JDK is filled with a ton of dumb "once upon a time we thought this was okay..." things that don't properly encode the correct modern idiom

For a long time I've wanted a sort of "local deprecation" tool where we could have a list of things in the JDK that shouldn't be used, and any direct reference to them would cause our build to fail.

https://errorprone.info/ can be configured to look at the AST and warn or reject a lot of specific problems.

We use https://github.com/policeman-tools/forbidden-apis for that.

Yes, it absolutely is! But then so are all other languages of its vintage. Part of learning a programming language is learning that.

Newer languages definitely have an advantage here, in that they haven't been around long enough for people to have figured out which bits of them are dumb.

It's worse. In 1.4 they added URI because URL is very flawed. You should never use URL. The equals method actually does a DNS resolve and compares the ip addresses. This means that comparing two URL's on the same server will always return true when compared. A lot of URL's you compare will give you true as there are a lot of sites run on the same machine with the same ip address.

Had this happen in production in a third party library we used many moons ago. Sysop came and asked us why we did six figure DNS lookups over a short period of time (24h? Less? Don't remember).

Would probably have gone unoticed at most AWS/GCP/Azure shops today.

Worse was when I had somebody adding the ip address as an Inet4Address on every message passed between machines in a production environment that explicitly didn't have DNS (banks have occasionally very odd ideas about securing subnets). Every single message was doing a reverse DNS lookup and then timing out. And there were a _lot_ of messages.

Wait, seriously? Did whoever designed that have any idea what URLs actually were? Even without DNS, comparing the hosts is no way to compare URLs. I can't think of a single example of two 'equal' URLs whose strings don't match (up until the parameters, at least)...

Yes - bear in mind the URL class has been around since 1995, when the landscape was somewhat different!

At that point, URLs resolving to the same IP were considered equal, even if the host names were different. Even now, there’s no real difference between say “http://example.com” and “http://example.com:80”; it would have been reasonable to consider these equal.

http://internalserver/resource

http://internalserver.initech.com/resource

Those are certainly not equivalent, as the 1st would not even resolve in the majority of environments. I'm assuming the 2nd host is a reverse proxy for the 1st? Unless that fact is part of your design assumptions (which it certainly can't be for a general URL class in a standard library), those should be considered different.

If the two hostnames resolve to the same IP address, they are equivalent. This could happen if initech.com was a default domain. This is a very standard situation in internal networks which i am surprised you are not familiar with.

I am quite familiar with that kind of setup and it's even further from equivalent than what I assumed you were referring to. Shared web hosting is the common example, but some other protocols are capable of distinguishing between hostnames.

google.com and maps.google.com resolve to the same address but are not equivalent. Even if your example and many others are equivalent, there are many that aren't. A general library should not make assumptions like that, unless they hold 100% of the time.

You asked for a single example of two 'equal' URLs whose strings don't match up, and now you've got one.

Looking back, I did phrase it ambiguously. What I meant was two URLs that are equal by definition, (no matter the server config, assuming standards compliance). A (general) library should make no more assumptions than the standard it implements. What I was asking about were cases, similar to http://h/p?x1=a&x2=b being equal to http://h/p?x2=b&x1=a since query parameter order is defined to not matter.

The spec I am mostly familiar with is, however, rather new, and whatever standard controlled URLs at the time (if any) might have made more assumptions.

How about http://localhost http://::1 and http://0:0:0:0:0:0:0:1 ?

Wow. And of course .equals is a synchronous method, so the whole thread blocks on a network operation whenever you do that.

Helluva way to thread starve your application. :(

https://docs.oracle.com/javase/7/docs/api/java/net/URL.html#...

`URI.create("https://example.com")`

Reply on news.ycombinator.com