Why isn't java.io.File deprecated?

Question

Since Java 7 there the java.nio.file package. So why is java.io.Filestill not deprecated in Java 8?

Related: http://stackoverflow.com/questions/6903335/java-7-path-vs-file — Radiodef, May 30 '15 at 15:02
@Radiodef different questions. This is "NIO.File" versus "IO.File", the link is "File" versus "Path". Both interesting questions but different. — kervin, May 30 '15 at 15:50
@kervin `Path`/`Files` are the replacement for `File` so it's very much related. There is some discussion over there about deprecation, but not so much with respect to "why". This question is like a follow-up to that one. — Radiodef, May 30 '15 at 15:54

Stephen C · Answer 1 · 2020-07-05T23:18:28.367

8

It is not deprecated because it is not broken. Or more precisely, because the Java team and/or Oracle management do not think it is sufficiently broken to warrant the level of disruption and pushback that deprecation of File would cause¹.

Oracle (and Sun before them) reserved deprecation for APIs that were deemed to be harmful / dangerous to use, and impossible to fix without breaking binary (or semantic) compatibility.

The java.io.File API is merely old-fashioned and clunky², but not directly harmful. There are other standard APIs that depend on File, not to mention many 3rd party APIs and (probably) 100's of millions of lines of customer code. There is no need to signal to the world that all of that code needs to be overhauled.

^{1 - Obviously, some people will disagree with that.}

^{2 - @fge points out that some File methods don't behave correctly on some platforms (particularly Windows / AD) in some versions of Java. However, those were / are implementation bugs, not fundamental API flaws. On UNIX / Linux platforms, the methods semantics are more or less correct².}

^{3 - A couple of "less correct" aspects are that File.length() returns zero for files in the "/proc" tree, and that strange things happen when you access a FAT file system mounted on Linux and try to access if from Java.}

edited Jul 05 '20 at 23:18

answered May 30 '15 at 15:06

Stephen C

698,415
94
811
1,216

2

"because it is not broken"? [That's a joke, right?](http://java7fs.wikia.com/wiki/Why_File_sucks) – fge May 30 '15 at 15:14
2

No. It is not a joke. The API is not elegant, and not (by today's standard) well designed, but the API methods all work as described by the javadocs. The fact that they work means that they are not broken. – Stephen C May 30 '15 at 15:36
There is a lot of hyperbolic use of the word "broken" in the programming world. But you wouldn't call a car that was 10 years old and used too much gas "broken". And this is the meaning of "broken" that I am using here. – Stephen C May 30 '15 at 15:39
Sorry but even that is wrong. For instance, `.canWrite()` doesn't work as documented on Windows. `Files.isWritable()` does however. – fge May 30 '15 at 15:41
Really? But more importantly, do you really that is enough to justify the pain of deprecating `File`? On the scale of "brokenness" that is nothing like broken enough to justify deprecating even that method, let alone the entire class. Besides, the brokenness is arguably in the Java on Windows implementation rather than the API itself. – Stephen C May 30 '15 at 15:44
@fge - If you were referring to this bug - http://bugs.java.com/view_bug.do?bug_id=4939819 - it was fixed in Java 7. – Stephen C May 30 '15 at 15:51
Well, as I see it, unfortunately, `File` is here to stay; but its innumerable shortcomings sort of have gone unnoticed except by people like me who take filesystem related jobs seriously; I'd have never dreamt of doing any serious fs job in Java before JSR 203. In that sense, `File` is really broken. And I believe not enough effort is put into steering Java users to the new API, in spite of its age. – fge May 30 '15 at 15:57
As to the bug you mention, no, it's the opposite; `.canWrite()` would return true whereas in fact the user didn't have the necessary privileges. This was in an AD environment. – fge May 30 '15 at 16:01
@fge - The keepers of the Java standard take a different view. Admittedly (2018) there is now more willingness to force the issue with things like withdrawal of Applets / JWS, closing off the internal APIs, etc. But that only seems to happen when the motivation is to simplify / reduce cost / increase revenue for Oracle. – Stephen C Oct 08 '18 at 23:41

score 3 · Answer 2 · edited May 04 '23 at 16:35

Because it is too ingrained within the JDK.

File has been there since the early days of Java; and in spite of its innumerable flaws (some of them listed here, but there are others), the amount of effort required to migrate all the code to the "new" JSR 203 API (which is already 4 years old!!) is immense.

The main problem is in fact the awareness of JSR 203, or lack thereof; even today, the vast majority of tutorials on the net still use File; the best one can do is write more tutorials using JSR 203, more code using it etc etc.

I am in fact one of the main proponents of the new API, to the point of being annoying on this aspect :), but I do have code to prove my point:

a filesystem over FTP,
another over dropbox,
another over box.com,
a helper library to develop new filesystems,
and finally a helper library complementing the JDK's Files (and fixing a few bugs in the process).

At this stage, it is a matter of patience; answering questions on SO using the new way, or even old questions etc. And it's an uphill battle.

Is this really why it isn't *deprecated*, though? All those APIs which use `File` would still work with deprecation, only compiling with warnings. — Radiodef, May 30 '15 at 15:30
@Radiodef there is however the (little known) fact that a `Path` can be an entity which _is not_ on the default filesystem, ie your hard disk; that makes some core classes of the JDK, for instance `FileOutputStream`, non reproducible with JSR 203 (which is why there is `Files.newOutputStream()`). — fge, May 30 '15 at 15:34

score 2 · Answer 3 · answered May 30 '15 at 18:16

It's not just legacy. Newer APIs continue to use the File object over the ( Path + NIO.Files + Channel ) combination because it's a lot simpler API to understand.

I am not advocating its use. But just pointing out that the single old File Object API provides a single point for exposing the API that some developers seeking simplicity gravitate towards.

It is harder for many developers to grasp the difference between a Path and a File. They are two different things, that's why we still have java.nio.file.Files right alongside java.nio.file.Paths. A Path is like a URI, a locator, it doesn't have to point to anything. While a File is a concrete representation of a File-System object.

NIO separates these concepts, while the old API held them all in a single object. I don't think that's necessarily wrong per se. It just traps a lot of useful Path related API in a File object, where that API is useful beyond these objects.

So I suspect the way forward might be "How much API do you need?" If you need the improved functionality of Channels, increased independence of Paths, etc. then NIO is definitely the way to go without option really.

If you're a junior developer or a student who needs a quick and basic Object-oriented way for opening a File-System object and running a few standard FS API calls before closing, why not use a simpler File object? Java isn't just for experts after all.

Why isn't java.io.File deprecated?

3 Answers3