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

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％的时间。

第一线不就是浪费时间吗？您会从cal到Calendar.getTime()获得一个Date，那么为什么要使用新的Date()调用创建一个日期，然后将其丢弃？特别是如果您正在对此进行基准测试...

// @放松：好抓。为什么不做一个帖子呢。

也许是因为美国人期望使用Date(整数年，整数天，整数月);-)

@unwind：当然，在这种情况下，这可能没有意义，但是您并不总是想要当前时间的日期，生日，到期日等。

@Scott：即使如此，您也可以通过cal.set(..)进行设置。我相信，当您打算使用日历时，不应像执行操作那样实例化日期。

@Adeel我明白您的意思，但是当现有系统需要一个java.util.Date时，您要提供一个java.util.Date。也许随着时间的流逝，对系统有了更深入的了解，就可以重构出旧的API了。

" LOC"是什么意思？

@NicolasBarbulesco LOC ==代码行

作为记录，请检查Java 8 new Date api！ oracle.com/technetwork/articles/java/

最初，Date旨在包含有关日期的所有逻辑，但是API设计人员最终意识到，到目前为止，他们所拥有的API严重不足，无法完全扩展以正确处理诸如时区，语言环境，不同日历，夏令时等

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

顺便说一句，在内部，这些方法(例如Date(int, int, int)构造函数)现在调用Calendar，因此，如果看到速度上的差异，则在调用Calendar时您做错了什么。

最重要的是：不是Java的Calendar API过于复杂，而是人为的日期概念，而Calendar的唯一问题是，它没有提供大多数常用用法的快捷方式。

java.util.Date重新使用公历的静态实例。 至少可以说这很有趣。 但是与为每个循环创建一个新的日历相比，它的性能更好。

Java Date API很久以来就受到批评，例如参见此线程。

您可能想查看Joda-Time或Apache Commons Lang，以了解其他的Date / Time实用程序。

我实际上回想起前一段时间在Parleys上观看Joda上的演讲时，印象深刻。 parleys.com/display/PARLEYS/。 至于追溯到1000s或LOC的100s，我不太

好点子。 Joda-Time后来被用作开发Java.time(现代Java日期和时间API)的基础。 它是Java 8的内置功能，也已移植到Java 6和7。这是我建议大家现在都使用的功能。

答案是可移植性。

类Date不太灵活。您可以定义日期，但不能进行任何转换为??其他日历格式。因此，Sun决定使用附加的类层次结构(Calendar)使它更加灵活。

但是，它不是很方便。

主要是因为原始的java.util.Date ated肿并且不完全了解时区并且不友好国际化。

但是，在值对象中，或者说作为数据类型，日期仍在使用中，并且使用得很好。只要使它明确不可变，就可以轻松进行。我倾向于认为它必须是不变的，出于其他目的，我们可以操纵日历。在需要进行大量操作的地方，应该考虑使用Joda-Time之类的东西。

[编辑]

只是不要在后面的代码中实例化Date。它没有用。您可能会为基准测试取得更好的结果。

从技术上讲，迈克尔·伯格沃德(Michael Borgwardt)的回答是最好的。

但是，为什么他将人类的太阳系布局方式归咎于人类呢？

好的，我们想到了秒，分，小时的想法。

但这不是我们的错，认为地球的日子是近似的(取决于我们所说的是真正的太阳日，平均太阳日还是恒星日，每一个周期都是周期性且随机变化的)。地球绕太阳公转的时间大约是365天不是我们的错，月亮绕地球公转的大约27.3天不是我们的错(取决于我们是否在谈论恒星，定理的天体，热带，异乎寻常或龙血(结节)月)。

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

上尉队长再次罢工！ 无需复制，只需指出。 en.wikipedia.org/wiki/Gregorian_calendar

当然，没有人使用任何其他日历格式，但是新的API增加了为99％的普通情况编写的代码量，因此对于LoC付钱的Java程序员来说，这是一个很大的福音。

高可用性，可以肯定的是，在当今时代，LoC是否可以用作衡量生产率的指标？

有人希望这样做，但也许Sun的老兄一直在生产类似这样的API，但事情没有变……