Hacker News Reader

Comment by eknkc | Hacker News Reader

The "URL.openConnection()" API has always looked out of place to me. I thought it was deprecated at some point but guess not. It feels backwards. Like you would not do "select * from tbl".execute(db)..

There was something more fucked up about the URL API which I can not remember. I think it triggers blocking DNS resolution on construction or something. Haven't written Java for more than 10 years though. Might be mixing something up.

View on HN

When you do equality checks on two URL instances, it checks to see if they resolve to the same IP address by hitting up DNS. This is problematic because equality checks happen implicitly all the time, e.g. if you're putting URLs into a hashtable.

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

No shot this is _ever_ what is actually meant by ‘if urlA == urlB’

Well, remember, this is Java, so `if (urlA == urlB)` just does standard object equality, the IP lookup is only done for `if (urlA.equals(urlB))` :)

This is Java, so you should always do `Object.equals(urlA, urlB)`, on the off-chance urlA is null!

(I do not miss working in Java haha)

It's still insane behavior. This implementation is effectively a sharp edge in the dark. Have fun.. :-/

Yes. Use the newer URI class instead if you want a value object without “smarts”. URL instances also contain a URLStreamHandler, which means that two URL instances that compare equal can still have different URLStreamHandlers that handle the URL differently. Instances of the class URL are really service objects.

You're probably thinking of .equals for URL, which does DNS resolution. The equality can therefore change depending on your network connection.

Not sure what's worse: the potentially changing equality, that you can get blocking i/o on something as supposedly local as using URL as keys in a hashmap, or the fact that identical paths on different hostnames that happen to resolve to the same IP are decidedly not the same resource ever since http 1.1 introduced the Host header.

It's a shame that Java missed the opportunity to duplicate all functionality expect the absurd equality on URI (including weirdos like openStream), so that the old URL could properly focus on celebrating xkcd:1172:workflow without doing too much harm.

What's the sin of File by the way, besides not being quite as convenient when interacting with modern API? Unfortunately the article is very silent about why it needed to be substituted instead of extended. I smell a similar story as URL vs URI, just not quite as bad?

File is from java.io, while Path is from java.nio (New I/O), which is a complete rethink of how I/O works, going from a "steam of bytes" paradigm to one of buffers and channels, enabling non-blocking I/O and DMA transfers.

In particular, File conflates several concepts: a filesystem, a path to a file in that filesystem, and a file's contents as byte streams. Path only represents a path, you need to use a FileSystem object to read from a file at that path, and you get a Channel for reading/writing that is used to fill a Buffer.

However, File does not need to be substituted. java.io is not deprecated nor is it slated for deprecation, and there are easy ways to convert from File to Path and vice-versa.

But nothing in File is tied to "stream of bytes", it's really just an immutable ID that may or may not point at an entity in a file system. What it adds is operating on filesystem attributs in a best effort WORA way, which leaves room for improvement (nio allows decidedly non-WORA digging into details I think?), but is very valuable to have because it satisfies most use cases in a more convenient way.

As you said, File won't go away. But it really does not feel right to not have File implement Path, or perhaps a subset of Path that would be good enough for all those use cases where something outside the identifier acts on the identified entity. Every .toFile() and .toPath() is a little defeat in API evolution, and there are a lot of those. Do they consider addition of an new interface, to an existing class a break of compatibility? On 17 windows (that's what I happen to be looking at), a chain of toPath/toFile/toPath won't even give you a symmetrically bound pair of immutables, toPath is memoized but toFile is not. Should not have been too hard keeping a provenience reference on the other side, or have memoization on both sides?

That seems insane to me—two identical urls can trivially resolve to distinct IP addresses. Not to mention doing IO on what looks to be a simple computation.

It's been a while for me too, but I think I recall common advice to use java.net.URI instead of java.net.URL wherever possible, at least partly for that reason. Also, the javadocs of URL now state: "The java.net.URL constructors are deprecated. Developers are encouraged to use java.net.URI to parse or construct a URL."

Reply on news.ycombinator.com