Java：路径与文件

Posted 2023-02-16

【中文标题】Java：路径与文件

【英文标题】：Java: Path vs File

【发布时间】：2011-10-17 17:10:16

【问题描述】：

对于用 Java 7 编写的新应用程序，是否有理由再使用 java.io.File 对象，或者我们可以认为它已弃用？

我相信java.nio.file.Path 可以做任何java.io.File 可以做的事情，甚至更多。

【参考方案1】：

众所周知，java.nio 包中的类使用路径实例，而不是文件实例。如果尽可能使用 java.nio，建议使用 Path 类。

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

【参考方案2】：

长话短说：

java.io.File 很可能永远不会被弃用/不受支持。也就是说，java.nio.file.Path 是更现代的java.nio.file 库的一部分，并且可以做所有java.io.File 可以做的事情，但通常以更好的方式，等等。

对于新项目，请使用Path。

如果您需要 File 对象作为旧版对象，只需调用 Path#toFile()

从文件迁移到路径

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

【讨论】：

您可以在此处阅读 Oracle 的 cmets 中的差异：docs.oracle.com/javase/tutorial/essential/io/legacy.html

另请注意，“文件”（复数形式）不已被弃用。它本质上是一个抽象类，对 Path 对象进行操作，并执行旧 File 类的许多功能，例如 isDirectory() 或 exists()

现在我想知道：为什么 JavaFX 8 中的新 File/FolderChooser 对话框仍然使用 File 而不是 Path？

路径是一个接口。要创建实例，请使用 Paths.get(filename)。这可能是因为必须编写 Files.exists(Paths.get(filename)) 而不是 new File(filename).exists() 导致仍然使用旧 API 的混淆。

Path 可以更轻松地修改为使用resolve(...)“添加孩子”或使用getParent() 等“上移一级”，而File 不能。基本上，一旦您完成了 Path 的修改，您通常会将其转换为 toFile()，以便可以将其发送到旧方法中，例如 FileInputStream 构造函数。

【参考方案3】：

Java.io.File 未被弃用。是的 java.nio.file.Path 更好，但只要还有很多程序和教科书使用 Java.io.File，如果只是出于遗留原因，它不应该被认为是弃用，它太重要了。这样做只是在工作中丢了一个扳手，而不会获得全部收益。例如，android 框架将 File 用于其一些基本的文件处理功能，还有许多其他功能。

【讨论】：

他没有问Path是否更好。他询问File 是否已被弃用。

@EJP 我认为你有点过于迂腐了。 OP 确实询问了 java.io.File 是否已被弃用，我回答说......他还说“我相信 java.nio.file.Path 可以做 java.io.File 可以做的所有事情，甚至更多。”我只是在确认他的评论，几乎不值得一票否决。

【参考方案4】：

我们可以认为它已被弃用吗？

不，您不能认为它已被弃用，除非并且直到它在 File Javadoc 中如此标记。

【讨论】：

即使这是“因为 RFC 这么说”的答案之一，我也不认为这是一个好的答案。很明显 File 将被 Path 替换。如果您想提前，您可以立即开始使用 Path 并在需要时使用 toFile()。

@Chris 自从 JDK 在 1.02 中更改了 AWT 事件模型以来，从未从 JDK 中删除任何内容。这根本不是“显而易见的”。错了。

@downvoters 这个答案本质上是一个重言式。这不可能是错的。 NB 在我写这个答案的五年里，Java 8 随后出现了，java.io.File 仍然没有被删除甚至被弃用，Javadoc 中仍然没有任何内容表明这些事情都会发生。跨度>

@EJP 我刚刚赞成你的评论。但是，当您说答案是重言式时，我并不完全确定您是对的。这个问题可能应该因为“基于意见”而被压制，是“我们可以考虑它已弃用”。嗯，是的，OP 和其他任何人可以，但事实并非如此。

@mikerodent 我认为这只是对问题的真正含义的故意误读。也是部分引用。

【参考方案5】：

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

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

JDK 类很少被弃用。 您可以在 the JDK 8 API deprecates list 上看到自第一个 JDK 以来不推荐使用的所有类。 它只包含 Oracle 文档和 Java 社区不鼓励使用的一小部分类。java.util.Date、java.util.Vector、java.util.Hashtable... 那些有很多缺陷的类不会被弃用。 但为什么 ？ 因为从概念上讲，deprecated 的含义仍然存在，但不鼓励使用，因为它肯定会被删除。 数以千计的程序依赖于这些设计不佳的类。 对于这样的类，Java API 开发者不会给出这样的信号。

@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 可以做的所有事情 等等。

你有答案。

This oracle tutorial 关于遗留 IO 的信息证实了您的想法。

在 Java SE 7 版本之前，java.io.File 类是 用于文件 I/O 的机制，但它有几个缺点。

许多方法在失败时并没有抛出异常，所以它是 无法获得有用的错误信息。例如，如果一个文件 删除失败，程序将收到“删除失败”但 不知道是不是因为文件不存在，用户不存在 有权限，或者有其他问题。

重命名方法在不同平台上的工作方式不一致。有 对符号链接没有真正的支持。

希望对元数据提供更多支持，例如文件权限、文件 所有者和其他安全属性。

访问文件元数据效率低下。

许多 File 方法无法扩展。请求大目录 在服务器上列出可能会导致挂起。大目录可以 还会造成内存资源问题，导致拒绝服务。

不可能编写可以递归行走的可靠代码 如果有循环符号，则文件树并适当响应 链接。

java.io.File 有这么多缺点，我们真的没有理由将这个类用于新的开发。 即使对于使用java.io.File 的遗留代码，Oracle 也会提示使用Path。

也许您有使用 java.io.File 的遗留代码并且想要 以最少的方式利用 java.nio.file.Path 功能 对您的代码的影响。

java.io.File 类提供了 toPath 方法，该方法将一个 旧式 File 实例转为 java.nio.file.Path 实例，如下：

Path input = file.toPath();

然后，您可以利用丰富的功能集 路径类。

例如，假设您有一些删除文件的代码：

file.delete();

您可以修改此代码以使用 Files.delete 方法，如下所示：

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

【讨论】：

简而言之，如果她/他愿意，她/他确实可以考虑它已弃用。

@mike 啮齿动物。确切地。从概念上讲，她/他应该，但出于解释的原因，在 Javadoc 方面并非如此。

【参考方案6】：

对于用 Java 7 编写的新应用程序，是否有任何理由使用 java.io.File 对象是不是已经被弃用了？

这有点像说：“拿破仑应该入侵俄罗斯，还是这些球芽甘蓝真的好吃吗？”

至于问题的第二部分，您确实可以认为它已弃用。截至 2018 年 1 月，它没有被弃用。但是没有什么可以阻止您考虑。这是否会在今生或来世为你带来任何好处是不可能的。

【讨论】：

我不明白你的比喻。

任何“或”问题都应该提出两个合乎逻辑的替代方案，这两个方案基本上都回答了同一个问题。

抱歉，在这种情况下，这听起来很迂腐。这个想法是“我想使用File。我应该，是还是不是？”

是的，我同意这是一个很重要的问题......尤其是因为许多现有的第 3 方 API 仍然使用 File。它不会很快死去。

it isn't deprecated. But there's nothing to stop you *considering* it so 哈哈。

【参考方案7】：

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

基本上 file.Path 将是从现在开始的方式，但众所周知，Java 人们倾向于保持向后兼容性，所以我想这就是他们离开它的原因。

【讨论】：

请更新链接好吗？我想阅读这篇文章。

很遗憾，我在 oracle 网页上找不到原始文章。这是来自 Wayback 机器的版本：web.archive.org/web/20090601091119/http://java.sun.com/…

我在正常的 Oracle 端再次找到了这篇文章 - 添加了回答链接。

【参考方案8】：

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

【讨论】：

Path 对象可以使用Path.toFile() 转换为 File 对象，然后使用标准 API。

所以你的答案是“是但不是”？