java.util.Date 和 java.util.Calendar 是不是已弃用？

Posted 2023-02-26

【中文标题】java.util.Date 和 java.util.Calendar 是不是已弃用？

【英文标题】：Are java.util.Date and java.util.Calendar deprecated?java.util.Date 和 java.util.Calendar 是否已弃用？

【发布时间】：2018-07-19 05:09:21

【问题描述】：

似乎新的 java.time API 提供了 java.util.Date 的所有内容等等。 自 Java 8 以来有更新的java.time API 时，是否有任何理由使用java.util.Date？ 应该完全避免java.util.Date 和java.util.Calendar 吗？

【问题讨论】：

支持遗留代码

我记得，java.util.Date 中的几乎所有内容自 JDK 1.1 版以来都已被弃用，从那时起更喜欢Calendar

来吧，在研究上做了哪些努力？你有 5k 的代表，你应该能够发现这样一个微不足道的问题表明明显缺乏努力！为什么还要谈论java.util.Date？自 Java 1.1 起，它的所有业务方法都已被弃用。您真的必须支持大部分在 1996 年 1 月 (Java 1.0) 和 1997 年 2 月 (1.1) 之间编写的应用程序吗？

@OlivierGrégoire 并不是说​​我捍卫可怕的班级java.util.Date，而是真正的业务方法，如getTime() 或after(Date) 或before(Date) 不会被弃用，并且可以在没有任何警告的情况下使用它们是为（Date 就像一个即时类型）而设计的。为了公平起见，我提到了这个事实。遗留代码可以在生产代码中存活很长时间，这仅仅是因为迁移旧代码可能需要太多的努力或成本。

@OlivierGrégoire 是的，当我谈到方法的弃用时，我已经理解你了，但是我提到的最常用、最重要和真实的生产业务方法并没有被弃用。当然，Date 实际上就像一个包裹着长条的薄包装纸。人们可以完全忽略不推荐使用的东西，Date 仍然按设计工作，即即时类型。如果有人使用过时的方法，那么他/她做错了什么。

【参考方案1】：

简短回答： 新 API java.time 比旧世界的 java.util.Date 和 java.util.Calendar 要好得多。所以是的，新的代码应该首选新的 API。

快速概览：有一次我为各种日期时间库写了comparison of features in table form。几乎没有 java.time 缺失但存在于旧世界的功能：

可配置的 gregorian/julian 转换 基于类FieldPosition的打印（用于Swing-component FormattedTextField）

关于弃用： 虽然自 Java 1.1 以来java.util.Date 的大部分内容都已弃用，但该类本身（以及java.util.Calendar）并未正式弃用，只是宣布为事实上的遗留物。旧类的支持对于向后兼容遗留代码的目标仍然很重要。所以甲骨文可能在未来的任何时候都不会停止支持。但也许甲骨文会申请更多sophisticated deprecation strategies。

未来发展：有趣的是，Java-8 的发布不仅包含了一个全新的日期/时间 API (java.time)，而且还看到了对 java.util.Calendar 的一些增强，例如Calendar.Builder或SHORT_STANDALONE等。好吧，我只能推测，但这似乎也表明Oracle不愿意在不久的将来停止对旧API的支持。