为什么大多数java.util.Date方法都已弃用？

Question

当您查看java.util.Date类的javadoc时，不推荐使用大多数方法。为什么这样做？

Answer 1

嗯，原因有两个。这是日期和时代概念的一个非常差的实现，它被Calendar类所取代。

Calendar课程虽然有所改进，但也有很多不足之处，因此对于严肃的日期/时间工作，每个人都推荐Joda-Time。 Java 8带来了由java.time.* package定义的Joda-Time启发的新JSR-310，旨在取代旧的日期/日历类。

编辑：针对实施效果差的具体问题，有很多原因。 JavaDoc总结如下：

  

不幸的是，这些功能的API不适合国际化。

除了这个一般性缺陷（包括缺少时区组件以及在DateFormat中更好处理的日期格式以及无法使用非公历日历表示的问题），有一些具体的问题确实伤害了Date班级，包括年份与共同时代相比1900年的偏差。

Calendar有自己的问题，但即使早在JDK 1.1中，java.util.Date显然不会削减它。尽管Calendar可以说是最糟糕的JDK API，但它已经用到版本7来尝试解决它。​​

Answer 2

• Date是可变的
• Date不支持时区

后者导致它被Calendar取代。前者与易用性相结合，导致两者都被Joda-Time / JSR-310（java.time.* package）取代

Answer 3

他们被弃用了，因为在他们想把JDK赶出家门的那天，Date被写得尽可能快。

事实证明日期和日历很难。因此，为了处理使用日历的难题，他们创建了更多的Calendar类。

他们弃用了Date方法并委托给了Calendar，因为他们不想改变现有Date方法的行为，并且可能会破坏现有的应用程序。

Answer 4

以下是Oracle的直接答案：http://www.oracle.com/technetwork/articles/java/jf14-date-time-2125367.html

  

Java开发人员长期存在的问题是对普通开发人员的日期和时间使用情况的支持不足。

     

例如，现有的类（例如java.util.Date和SimpleDateFormatter）不是线程安全的，导致用户可能出现并发问题 - 而不是普通开发人员期望处理的问题。写日期处理代码。

     

某些日期和时间类也表现出相当差的API设计。例如，java.util.Date中的年份从1900开始，月份从1开始，数天从0开始 - 不太直观。

     

... java.util.Date表示时间轴上的一个瞬间 - 一个自UNIX纪元以来毫秒数的包装器 - 但是如果你调用toString（），结果表明它有一个时区，导致开发人员混淆。

Answer 5

我不知道它已被弃用的官方原因，但据我所知GregorianCalendar和Joda-Time支持日期操作，这意味着您可以添加，例如，日期到某一天，并相应地更新其月份和年份。

例如，假设您想计算当前日期之后的第二天，今天是5月31日;使用java.util.Date，你只需要getDays() +1，它返回32，你必须自己处理当前月份没有32天的知识;使用GregorianCalendar或Joda.time，将一天添加到5月31日会产生一个代表6月1日的对象，从而隐藏您视线的复杂性。