我会完成@mmcrae非常好的回答。

还有什么理由继续使用java.io.File对象吗 认为它已弃用?

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.

@EJP的回答非常正确:

除非在Javadoc中有这样的标记。

所以，我认为你的问题更有意义: “如果我们有选择，我们应该使用java.io.File还是java.nio.file. path进行新开发，如果答案是java.nio.file。Path，你能在遗留项目中使用java.io.File轻松地利用java.io.File吗?”

我相信java.nio.file.Path可以做java.io.File可以做的所有事情 和更多。

你已经有了答案。

这个关于遗留IO的oracle教程证实了您的想法。

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.

java.io有这么多缺点。文件，我们真的不需要理由使用这个类进行新的开发。 甚至对于使用java.io的遗留代码。文件，Oracle提示使用路径。

也许您有使用java.io.File的遗留代码，并且希望这样做 充分利用java.nio.file.Path功能 对代码的影响。 file类提供了toPath方法，该方法将一个 File实例转换为java.nio.file.Path实例，如下所示:

Path input = file.toPath();

的丰富特性集 类路径。 例如，假设你有一些删除文件的代码:

file.delete();

你可以修改这段代码来使用Files.delete方法，如下所示:

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

查看这篇文章关于更多信息- http://www.oracle.com/technetwork/articles/javase/nio-139333.html

基本文件。Path将是今后的发展方向，但众所周知，Java的人们倾向于保持向后兼容性，所以我猜这就是他们离开它的原因。

我会完成@mmcrae非常好的回答。

还有什么理由继续使用java.io.File对象吗 认为它已弃用?

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.

@EJP的回答非常正确:

除非在Javadoc中有这样的标记。

所以，我认为你的问题更有意义: “如果我们有选择，我们应该使用java.io.File还是java.nio.file. path进行新开发，如果答案是java.nio.file。Path，你能在遗留项目中使用java.io.File轻松地利用java.io.File吗?”

我相信java.nio.file.Path可以做java.io.File可以做的所有事情 和更多。

你已经有了答案。

这个关于遗留IO的oracle教程证实了您的想法。

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.

java.io有这么多缺点。文件，我们真的不需要理由使用这个类进行新的开发。 甚至对于使用java.io的遗留代码。文件，Oracle提示使用路径。

也许您有使用java.io.File的遗留代码，并且希望这样做 充分利用java.nio.file.Path功能 对代码的影响。 file类提供了toPath方法，该方法将一个 File实例转换为java.nio.file.Path实例，如下所示:

Path input = file.toPath();

的丰富特性集 类路径。 例如，假设你有一些删除文件的代码:

file.delete();

你可以修改这段代码来使用Files.delete方法，如下所示:

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

是的，但是许多现有的api，包括Java7自己的标准api，仍然只能使用File类型。

长话短说:

java.io.File很可能永远不会被弃用/不支持。也就是说，java.nio.file. path是更现代的java.nio.file库的一部分，它能做java.io.File能做的一切，但通常以更好的方式，而且更多。

对于新项目，使用Path。

如果你需要一个File对象，调用Path#toFile()

从文件迁移到路径

这个Oracle页面突出了不同之处，并将java.io.File功能映射到java.nio.file lib(包括Path)功能

Janice J. Heiss和Sharon Zakhour的文章，2009年5月，讨论JDK 7中的NIO.2文件系统

众所周知，java中的类。nio包适用于路径实例，而不是文件实例。如果使用java，建议使用Path类。只要可能，蔚来汽车。

现在，有时您将不得不使用File类。这是因为方法或构造函数希望将File实例作为参数，但当您有选择时，请确保使用Path而不是File。