为什么不推荐使用 java.io.File？-技术脚本

从 Java 7 开始就有 java.nio.file 包。那么为什么 java.io.File 在 Java 8 中仍未被弃用？

它没有被弃用，因为它没有被破坏。或者更准确地说，因为 Java 团队和/或 Oracle 管理层认为它的破坏程度不足以保证对 File 的弃用会导致的破坏和抵制程度1。

Oracle(和他们之前的 Sun)保留弃用被认为有害/危险使用且在不破坏二进制(或语义)兼容性的情况下无法修复的 API。

java.io.File API 只是老式且笨拙的2，但没有直接危害。还有其他依赖于 File 的标准 API，更不用说许多第 3 方 API 和(可能)数以百万计的客户代码行了。无需向世界发出信号，即所有代码都需要大修。

1 - 显然，有些人会不同意这一点。

2 - @fge 指出某些 File 方法在某些 Java 版本的某些平台(尤其是 Windows / AD)上的行为不正确。然而，那些是/是实现错误，而不是基本的 API 缺陷。在 UNIX / Linux 平台上，方法语义或多或少是正确的2。

3 - 一些"不太正确"的方面是 File.length() 为"/proc"树中的文件返回零，当您访问挂载在 Linux 上的 FAT 文件系统并尝试访问 if 时会发生奇怪的事情来自 Java。

因为它在 JDK 中太根深蒂固了。

文件从 Java 早期就已经存在；尽管存在无数缺陷(其中一些在这里列出，但还有其他缺陷)，将所有代码迁移到"新"JSR 203 API(已经有 4 年历史！！)所需的工作量是巨大的.

主要问题实际上是对 JSR 203 的认识，或缺乏认识；直到今天，网络上的绝大多数教程仍然使用 File；最好的办法是使用 JSR 203 编写更多教程，使用它等更多代码。

我实际上是新 API 的主要支持者之一，以至于在这方面很烦人 :)，但我确实有代码来证明我的观点：

在这个阶段，这是一个耐心的问题；用新的方式回答关于 SO 的问题，甚至是老问题等。这是一场艰苦的战斗。

这不仅仅是遗产。较新的 API 继续使用 File 对象而不是( Path NIO.Files Channel )组合，因为它的 API 更易于理解。

我不提倡使用它。但只是指出，单一的旧文件对象 API 提供了一个单一的点来公开一些寻求简单性的开发人员倾向于使用的 API。

对于许多开发人员来说，很难理解 Path 和 File 之间的区别。它们是两个不同的东西，这就是为什么我们在 java.nio.file.Paths 旁边仍然有 java.nio.file.Files。 Path 就像一个 URI，一个定位器，它不必指向任何东西。而文件是文件系统对象的具体表示。

NIO 将这些概念分开，而旧的 API 将它们全部放在一个对象中。我认为这本身不一定是错误的。它只是在一个 File 对象中捕获了许多有用的 Path 相关 API，该 API 在这些对象之外很有用。

所以我怀疑前进的方向可能是"您需要多少 API？"如果您需要改进 Channels 的功能，增加 Paths 的独立性等，那么 NIO 绝对是没有选择的方法。

如果您是初级开发人员或学生，需要一种快速且基本的面向对象方式来打开文件系统对象并在关闭之前运行一些标准的 FS API 调用，为什么不使用更简单的文件对象呢？毕竟，Java 不只是为专家准备的。

为什么不推荐使用 java.io.File？