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?

Answer 1

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 correct2.}

^{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.}

Answer 2

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.

Answer 3

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.