Question

我最近继承的应用程序是关于构造函数的完全弃用警告：

Date d = new Date(int year, int month, int day)

有没有人知道或者可以指出为什么像这样简单的东西被这样的东西“替换”的原因：

Date d = null;
Calendar cal = GregorianCalendar.getInstance();
cal.set(1900 + year, month, day);
d = cal.getTime();

现在，显然弃用警告本身并不是一个问题，但是你能想象如果这个构造函数被删除，数百万的LOC会在痛苦中哭泣吗？

在我的基准测试中，后者需要大约50％的时间来执行。

Answer 1

最初，Date旨在包含有关日期的所有逻辑，但API设计人员最终意识到他们迄今为止所拥有的API严重不足，无法彻底扩展以正确处理时区等问题，区域设置，不同的日历，夏令时等等。

因此，他们创建Calendar来处理所有这些复杂性，并将Date降级为一个简单的时间戳，弃用其处理格式化，解析和单个日期字段的所有功能。

BTW，内部这些方法（例如Date(int, int, int)构造函数）现在调用Calendar，所以如果你看到速度不同，那么在调用Calendar时你做错了。

底线：这不是Java的Calendar API过于复杂，它是日期的人类概念，而Calendar的唯一问题是它提供的快捷方式并不多。最常见的用法。

Answer 2

Java Date API一直受到批评，例如参见this thread。

您可能需要查看Joda-Time或Apache Commons Lang以了解其他日期/时间实用程序。

Answer 3

答案是便携性。

班级Date不是很灵活。您可以定义日期，但不能将其转换为其他日历格式。因此，Sun决定使用额外的类层次结构（Calendar）来使其更加灵活。

尽管如此，它并不是很方便。

Answer 4

主要是因为最初的java.util.Date臃肿，并没有完全时区感知，也没有国际化友好。

但是，Date仍在使用，非常好，在Value Objects中，或者说是数据类型。只要你明确地使它成为不可变的，你就可以放心。我倾向于认为它必须是不可变的，为了其他目的我们有Calendar来操纵。在预期的操作很多的地方，人们应该考虑像Joda-Time这样的东西。

<强> [编辑]

只是不要在后面的代码中实例化Date。它毫无用处。您可以为您的基准测试获得更好的结果。

Answer 5

当然，没有人使用任何其他日历格式，但是新的API增加了为99％常见案例编写的代码量，因此对于由LoC支付的Java程序员来说，这是一个很大的好处。

Answer 6

迈克尔博格沃德在技术上得到了最好的答案。但他为什么要责怪人类的太阳系布局呢？

好的，我们想出了秒，分钟和小时的想法。

但是，地球的日子是近似的，这不是我们的错（取决于我们是在谈论真正的太阳日，平均太阳日，还是恒星日，每一天都是周期性地随机变化）。地球围绕太阳运行的时间大约 365天并不是我们的错，而且月球围绕地球运行的轨道大约 27.3天不是我们的错。（取决于我们是在谈论恒星，朔望，热带，异常还是严苛（月份）月份）。

您是否因为日历没有考虑所有这些细节而感到高兴？那么我们的软件错误可能确实取决于月球的阶段。

为什么“新日期（int year，int month，int day）”已弃用？

6 个答案: