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.
