我正在审核我的同事刚刚做过的更改代码，并且他添加了一堆对Date.toMonth()，Date.toYear()和其他已弃用的Date方法的调用。所有这些方法都在JDK 1.1中被弃用了，但他坚持认为可以使用它们因为它们还没有消失（我们使用的是JDK 1.5）而且我说它们现在可能会在任何一天消失而且他应该使用它们Calendar方法。
Sun / Oracle是否真的说过这些事情何时消失，或@deprecated只是意味着你失去了风格点？
答案 0 :(得分：25)
关于API，......未指定它们将很快被删除。
Incompatibilities in J2SE 5.0 (since 1.4.2)：
来源兼容性
[...]
一般而言，该政策如下，但下面列出的任何不兼容性除外：不推荐使用的API是仅支持向后兼容性的接口。除非使用-nowarn命令行选项，否则只要使用其中一个，javac编译器就会生成警告消息。建议修改程序以消除使用已弃用的API，虽然目前没有计划删除此类 - 但JVMDI和JVMPI除外 - 完全来自系统。
即使在其How and When To Deprecate APIs中，关于实际删除已删除的API的政策也没有任何说法......
10年后更新，新JDK9+ Enhanced Deprecation澄清了折旧政策 有关详细信息，请参阅Jens Bannmann的answer Vojtěch Růžička之后的criticisms on JEP 277在此博文中详细介绍了这一点。
JDK的约定是，在某个Java版本中将JDK API标记为
forRemoval=true后，将在以下主要Java版本中将其删除。
这意味着 - 当Java 9中的某些内容被标记为forRemoval=true时，它应该在Java 10中被完全删除 使用标记为要删除的API时请记住这一点。请注意，此约定仅适用于JDK本身，第三方库可以自由选择他们认为合适的任何约定。
答案 1 :(得分：13)
他们不会离开。也就是说，它们通常被弃用，因为a）它们是危险的线程.stop（），或b）有更好的或至少更可接受的方式来做它。通常不推荐使用的方法javadoc会给你一个更好的方法提示。在您的情况下，建议使用日历。
虽然可以想象他们将来会被删除，但我不会赌它。如果有人曾经问过Java，那么他们可能是第一件事......
答案 2 :(得分：7)
一个问题是，您会看到许多关于使用弃用方法的编译器警告。如果您还使用弃用来逐步淘汰自己的代码，编译器警告将在噪声中丢失并失去意义。
答案 3 :(得分：4)
嗯，“尚未消失”和“永不消失”是两件截然不同的事情。这就是整个弃用点。他们可以在任何未来版本中消失。使用它们是您自己的风险主张。请注意，JDK的某些未来版本可能会使您的代码处于无法使用的状态。
答案 4 :(得分：4)
As of JDK 10，所有原始java.util.Date方法仍然存在，但这些和其他API现在可以explicitly marked删除。最近删除了其他API。
在Java 9之前，JDK中没有弃用的API（参见20 Years Of Java Deprecation）。
但是，作为名为Enhanced Deprecation的功能的一部分，JDK 9引入了@Deprecated(forRemoval=true)标志并将其添加到dozens of previously deprecated APIs。但是，java.util.Date方法不在其中。
此外，在语言历史上第一次，JDK 9 已删除以前弃用的API（如the Java SE 9 Specification中所述）。这些是模块化的障碍，并在JDK 8中被弃用。
JDK 10 marked more previously deprecated APIs for removal。再一次，java.util.Date方法得以幸免。
JDK 10还已移除 SecurityManager和Runtime类中的某些已弃用的API（如the Java SE 10 Specification中所述）。
所以要点是：
forRemoval标记之后的版本中可能无法删除它们（例如，在JDK 9中标记为Thread.stop()，但仍保留在JDK 10中），它可以发生得很快。forRemoval标志，下面的一个删除了API。例如，JDK 10删除的API已被弃用至少20年（自JDK 1.2起），所以有些人现在可能会感到惊讶。答案 5 :(得分：3)
我有更好的建议：您应该切换到JodaTime或JSR-310的预发布版本，而不是告诉他使用Calendar。 java.util.Date上的某些方法可能已弃用，但在我看来，应该弃用整个类，以及Calendar。 JSR-310的开发人员似乎同意，尽管我怀疑他们会咬紧牙关并弃用它。
没有特别的顺序，这是Date的错误：
其内部表示是自纪元以来的毫秒;因此，不能代表纪元之前的日期。
所有有用的方法（例如toString）首先根据当地时区标准化日期。使用UTC Date实例时，这可能会让真的烦人;你被迫使用Calendar，否则你会犯错误。
Calendar。它只是臭。可能会赢得有史以来最差API的奖项。
始终代表即时。无法表示特定日期或特定年份。无法表示无时区的日期值。
几乎没有有用的方法。参见例如JodaTime用于进行日期算术的流畅界面。
考虑到它是一个，应该被命名为Datetime。
答案 6 :(得分：2)
如果弃用的方法消失了，它们可能会破坏现有代码。
虽然维护一个干净的API很重要，但已弃用的方法并不适合任何人。当然，现在有更好的方法来做事，所以新的方法取代旧方法。但是，除了旧的那些之外，不会有任何好处（除了更清洁的API）。
将“弃用”视为“过时”，但不一定是“在砧板上”。
答案 7 :(得分：2)
已弃用的功能已被取代，应予以避免。尽管它们仍然存在于JDK中，但由于有更好的方法，因此不鼓励它们。这些方法留在API中以支持向后兼容性，但通常应该避免使用，因为它们可以在API的未来版本中删除。
技术上可以使用弃用的方法，但通常首先弃用它的原因是开发了更好/更快/更清洁的API。
答案 8 :(得分：1)
对于影响向后兼容性的变化，Sun往往非常偏执，所以我不希望这些方法很快就会消失。
但已弃用的方法可能会在将来的任何时候消失，并且通常会因某种原因而被弃用 - 或者因为它们不可靠，因为它们有令人不快的副作用，或者只是因为它有更好或更优雅的做事方式。该方法的JavaDoc通常会详细说明这些情况中的哪一个以及目前执行相同操作的可接受方式。很多时候，不推荐使用的方法已被替换为无论如何都调用“正确”方法的实现，所以你只需添加一个间接级别。
如果你使用这些方法，你也会有很多编译警告，这可能足以让它们本身避免......
答案 9 :(得分：1)
我肯定看到已弃用的功能消失了 - 从旧版本的Java到当前版本（我从1.1开始，有些东西明显不适用于1.4）。
其他语言处理弃用的方式不同 - 例如，过去Python已经知道在一两个版本之后删除已弃用的功能。