为什么“新的date(INT年,INT月,INT日)”弃用?

我最近inheritance的应用程序是关于构造函数的弃用警告完整:

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

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

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

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

在我短暂的基准testing中,后者花费了大约50%的时间来执行。

Date最初是为了包含所有有关date的逻辑,但是APIdevise人员最终意识到,他们到目前为止所使用的API是非常不足的,无法被正确地处理,例如时区,地区,不同的日历,夏令时时间等

所以他们创build了Calendar来处理所有这些复杂性,并将Date降级到一个简单的时间戳,弃用了所有处理格式化,parsing和个别date字段的function。

顺便说一句,内部这些方法,如Date(int, int, int)构造函数现在调用Calendar ,所以如果你看到速度的差异,那么你在做Calendar时做错了什么。

底线:Java的Calendar API过于复杂,它是date的人类概念,而Calendar的唯一问题在于它没有提供最常用的快捷方式。

JavadateAPI早已受到批评,请参阅此线程 。

您可能需要查看Joda-Time或Apache Commons Lang以获取其他date/时间实用程序。

答案是可移植性。

Date类不是很灵活。 您可以定义date,但不能转换成其他日历格式。 所以Sun决定使用额外的类层次结构( Calendar )来使其更加灵活。

尽pipe如此,这并不是非常方便。

主要是因为原始的java.util.Date是臃肿的,不能完全区分时区和不友好的国际化。

但是,Date对象仍然在使用中,或者说是数据types。 至于你明确不变,你可以轻松地去。 我倾向于认为它必须是不可变的,为了其他目的,我们有日历来操纵。 在很多操纵预期的地方,人们应该考虑像Joda-Time。

将post

只是不要在后面的代码中实例化date。 它没用。 您可能会为您的基准testing获得更好的结果。

当然,没有人使用任何其他的日历格式,但新的API增加了99%的常见情况下编写的代码量,所以对于由LoC支付的Java程序员来说,这是一个很大的好处。

从技术上讲,Michael Borgwardt有最好的答案。 但为什么他把太阳系的布局方式归咎于人类呢?

好吧,我们想出了几秒钟,几分钟和几小时的想法。

但地球日是近似的(这取决于我们是在谈论真正的太阳日,平均日太阳日,还是恒星日,每个date都是周期性的和随机的)。 地球绕太阳的轨道运行时间大约是365天,这不是我们的错,我们的错误在于地球周围的轨道大约是27.3天(取决于我们是否在谈论恒星,热带,不规则或龙脉(节日)月份)。

日历没有考虑到所有这些细节,难道不是很高兴吗? 那么我们的软件bug可能确实取决于月球的相位。