Java: Path vs File

For new applications written in Java 7, is there any reason to use a java.io.File object any more or can we consider it deprecated?

I believe a java.nio.file.Path can do everything a java.io.File can do and more.

Long story short:

java.io.File will most likely never be deprecated / unsupported. That said, java.nio.file.Path is part of the more modern java.nio.file lib, and does everything java.io.File can, but generally in a better way, and more.

For new projects, use Path.

And if you ever need a File object for legacy, just call Path#toFile()

Migrating from File to Path

This Oracle page highlights differences, and maps java.io.File functionality to java.nio.file lib (including Path) functionality

Article by Janice J. Heiss and Sharon Zakhour, May 2009, discussing NIO.2 File System in JDK 7

> can we consider it deprecated?

No, you can't consider it deprecated unless and until it is so marked in the File Javadoc.

Check this article about more info - http://www.oracle.com/technetwork/articles/javase/nio-139333.html

Basically file.Path will be the way to go from now on but as is widely known Java people tend to keep back-compatibility so I guess that's why they have left it.

I will complete the very good answer of @mmcrae.

> is there any reason to use a java.io.File object any more or can we > consider it deprecated?

JDK classes are very rarely deprecated.
You can see on the the JDK 8 API deprecates list all classes deprecated since the first JDK.
It contains only a little part of classes that the Oracle documentation and the Java community discourage to use.
java.util.Date, java.util.Vector, java.util.Hashtable... that are classes with so many defects are not deprecated.
But why ?
Because conceptually something of deprecated means still there but discourage to use as it will very certainly be removed.
Thousands of programs rely on these bad designed classes.
For such classes, Java API developers will not give such a signal.

Answer of @EJP is so really right :

> Not unless and until it is so marked in the Javadoc.

So, I think that your question would make more sense in its terms :
"As we have the choice, should we use java.io.File or java.nio.file.Path for new developments and if the answer is java.nio.file.Path, could you easily take advantage of java.io.File for legacy projects using java.io.File ?" > I believe a java.nio.file.Path can do everything a java.io.File can do > and more.

You have the answer.

This oracle tutorial about legacy IO confirms your thinking.

> Prior to the Java SE 7 release, the java.io.File class was the > mechanism used for file I/O, but it had several drawbacks. > > Many methods didn't throw exceptions when they failed, so it was > impossible to obtain a useful error message. For example, if a file > deletion failed, the program would receive a "delete fail" but > wouldn't know if it was because the file didn't exist, the user didn't > have permissions, or there was some other problem. > > The rename method didn't work consistently across platforms. There was > no real support for symbolic links. > > More support for metadata was desired, such as file permissions, file > owner, and other security attributes. > > Accessing file metadata was inefficient. > > Many of the File methods didn't scale. Requesting a large directory > listing over a server could result in a hang. Large directories could > also cause memory resource problems, resulting in a denial of service. > > It was not possible to write reliable code that could recursively walk > a file tree and respond appropriately if there were circular symbolic > links.

With so many drawbacks for java.io.File, we need really no reason to use this class for new developments.
And even for legacy code using java.io.File, Oracle gives hints to use Path.

> Perhaps you have legacy code that uses java.io.File and would like to > take advantage of the java.nio.file.Path functionality with minimal > impact to your code. > > The java.io.File class provides the toPath method, which converts an > old style File instance to a java.nio.file.Path instance, as follows:

Path input = file.toPath();

> You can then take advantage of the rich feature set available to the > Path class. > > For example, assume you had some code that deleted a file:

file.delete();

> You could modify this code to use the Files.delete method, as follows:

Path fp = file.toPath();
Files.delete(fp);

Yes, but many existing APIs, including Java7's own standard APIs, still work only with File type.

Java.io.File is not deprecated. Yes java.nio.file.Path is better, but as long as there are still plenty of programs and text books using Java.io.File, if only for legacy reasons, it should not be considered deprecated, its too important. Doing so would just be throwing a spanner in the works for no over all gain. For example the Android framework uses File for some of its basic file handling features, many other things do to.

It is known that classes in java.nio package work with Path instances, and not File instances. It's recommended practice to work with the Path class if using java.nio wherever possible.

Now sometimes you will have to use the File class. That's because the method or constructor wants to File instance as a parameter, but when you do have a choice, make sure you use the Path over the File.

> For new applications written in Java 7, is there any reason to use a > java.io.File object any more or can we consider it deprecated?

This is a bit like saying: "should Napoleon invade Russia, or are these Brussels sprouts really tasty?"

As to the second part of the question, you can indeed consider it deprecated. As of January 2018, it isn't deprecated. But there's nothing to stop you considering it so. Whether that will procure you any advantage in this life or the next is impossible to say.