Java: Path vs File
Solution 1
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
Article by Janice J. Heiss and Sharon Zakhour, May 2009, discussing NIO.2 File System in JDK 7
Solution 2
can we consider it deprecated?
No, you can't consider it deprecated unless and until it is so marked in the File
Javadoc.
Solution 3
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.
Solution 4
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);
Solution 5
Yes, but many existing APIs, including Java7's own standard APIs, still work only with File
type.
Related videos on Youtube
Comments
-
dogbane over 3 years
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 ajava.io.File
can do and more. -
jacktrades over 11 yearsPath objects can be converted to File objects using Path.toFile(), then use standard APIs.
-
Chris almost 11 yearsEven if this is one of these "Because the RFC says so"-Answers, I would not consider it as a good answer. It's pretty obvious that File will be replace by Path. If you want to be ahead of time you can start using Path immediatly and use toFile() where needed.
-
John B almost 11 yearsWould you please update the link? I would like to read this article.
-
LordDoskias almost 11 yearsUnfortunately I couldn't find the original article on the oracle web page. Here is a version from the wayback machine: web.archive.org/web/20090601091119/http://java.sun.com/…
-
user207421 about 10 years@Chris Nothing has ever been removed from the JDK since they changed the AWT event model in 1.02. It isn't 'obvious' at all. It's wrong.
-
Duncan Jones over 9 yearsI found the article again on a normal Oracle side - added link to answer.
-
user207421 over 9 yearsSo your answer is 'yes but no'?
-
Josiah Yoder over 9 yearsYou can read Oracle's comments on the differences here: docs.oracle.com/javase/tutorial/essential/io/legacy.html
-
Josiah Yoder over 9 yearsAlso note that "Files" (in the plural) is not deprecated. It is essentially an abstract class that operates on Path objects and performs many of the features of the old File class, such as isDirectory() or exists()
-
user207421 over 7 years@downvoters This answer is essentially a tautology. It can't be wrong. NB In the five years since I wrote this answer, Java 8 has subsequently appeared, and
java.io.File
is still neither removed nor even deprecated, and there is still nothing in the Javadoc to suggest that either of these things will ever happen. -
mike rodent about 7 years@EJP I just upvoted that comment of yours. However, I'm not entirely sure that you're right when you say the answer is a tautology. The question, which should probably have been squashed for being "opinion-based", is "can we consider it deprecated". Well, yes, the OP and anyone else can, but it isn't.
-
Tunaki about 7 yearsI don't understand your analogy.
-
mike rodent about 7 yearsAny "or" question should present two logical alternatives, both of which essentially answer the same question.
-
Tunaki about 7 yearsSorry, this sounds highly pedantic in this context. The idea is "I want to use
File
. Should I, yes or no?" -
mike rodent about 7 yearsNo offence taken. The way the question is posed invites an analysis of what's it's "really" asking, and you've given a reasonable interpretation. But it is a loaded question. By pointing out its curious nature I'm just drawing attention to the fact that it should really have been squashed as "opinion-based". As to your question: "yes". You say you want to, so use it. The OP wanted someone to say "don't use
File
, it's a bit rubbish", butFile
is still with us five or more years later. Maybe we should celebrate that? -
Tunaki about 7 yearsYeah I agree it's a loaded question... especially since that a lot of existing 3rd party APIs still use
File
anyway. It's not going to die anytime soon. -
Don Cheadle about 7 years
it isn't deprecated. But there's nothing to stop you *considering* it so
LOL. -
piegames over 6 yearsNow I'm wondering: why do the new File/FolderChooser dialogs in JavaFX 8 then still use
File
instead ofPath
? -
user207421 over 6 years@mikerodent I suggest that's just a wilful misreading of what the question is really about. Also a partial quotation.
-
user207421 over 6 years@downvoter If you downvote tautologies do you also upvote self-contradictions?
-
davidxxx over 6 years@EJP Sorry I would upvote. Bad manipulation on my smartphone. If you edit, I could reverse it.
-
mike rodent over 6 years@EJP Disagree. The question should have been squashed as "opinion-based". If the words "can we consider" had been absent it wouldn't have been posed in the first place.
-
mike rodent over 6 yearsIn short, she/he can indeed consider it deprecated if she/he wants.
-
davidxxx over 6 years@mike rodent. Exactly. Conceptually she/he should while it is not the case in terms of Javadoc for explained reasons.
-
Josiah Yoder over 6 yearsPath is an interface. To create an instance, use Paths.get(filename). It could be because of the confusion of having to write Files.exists(Paths.get(filename)) instead of new File(filename).exists() that the older API is still used.
-
user207421 about 6 years@mikerodent I don't understand your final sentence. You don't know what the OP would and wouldn't have 'posed'. And I don't see that the presence of the word 'can' makes any substantive difference.
-
user207421 about 6 yearsHe didn't ask whether
Path
was better. He asked whetherFile
was deprecated. -
Andrew S about 6 years@EJP I think you are being a little over pedantic. The OP did ask if java.io.File was deprecated and I answered that.. He also stated "I believe a java.nio.file.Path can do everything a java.io.File can do and more." I was merely confirming his comment, it was hardly worth a vote down.
-
MasterHD about 4 years
Path
can be more easily modified to "add children" withresolve(...)
or "move up one level" withgetParent()
, etc. whereasFile
cannot. Essentially once you have finished modifying the Path, you'll often convert ittoFile()
so it can be sent into legacy methods such as aFileInputStream
constructor.