我的应用我最近继承全是有关构造废弃警告的：为什么不推荐使用“新日期（int year，int month，int day）”？
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％的时间来执行。
最初，Date旨在包含所有有关日期的逻辑，但是API设计人员最终意识到，他们迄今为止所使用的API极其不足，无法完全扩展以正确处理诸如时区，区域设置等不同问题日历，夏令时等
所以他们创造Calendar来处理所有的复杂性，并退居Date一个简单的时间戳，贬它的所有功能，处理格式化，解析和个别日期字段。
顺便说一句，内部这些方法，如Date(int, int, int)构造函数现在调用Calendar，所以如果你看到速度的差异，那么你调用Calendar时做错了什么。
底线：它不是Java的Calendar API，它过于复杂，它的日期的人文理念，并与Calendar唯一的问题是，它提供了快捷的方式没有太大的最常见的用法。
答案是可移植性。
该类Date不是很灵活。您可以定义日期，但不能转换为其他日历格式。所以Sun决定使用额外的类层次结构（Calendar）以使其更加灵活。
尽管如此，它并不是非常方便。
Java Date API早已受到批评，例如参见this thread。
您可能想查看Joda-Time或Apache Commons Lang了解其他日期/时间实用程序。
主要是因为原始的java.util.Date变得臃肿，并且没有完全识别时区并且没有国际化友好性。
但是，Date仍然在使用中，并且非常好，在Value Objects中，或者说作为数据类型。只要你明确地使其不变，你就可以轻松地去。我倾向于认为它必须是不可变的，因为我们有Calendar来操作其他目的。在很多操纵预期的地方，人们应该考虑像Joda-Time。
[编辑]
只是不实例化的日期，在后者的代码。它没用。您可能会为您的基准测试获得更好的结果。
当然，没有人曾经使用任何其他日历格式，但新的API增加了代码编写的99％，常见的情况金额，所以它是由控制线支付Java程序员的一大福音。
Michael Borgwardt在技术上有最好的答案。但为什么他为我们的太阳系布局方式而责怪人类呢？
OK，我们想出了几秒钟的理念，分钟和小时。
但是这不是我们的错，是地球的一天是近似（取决于我们是否在谈论真正的太阳日，平均太阳日，恒星或一天，每一个周期和随机变化）。这不是我们的错，地球轨道绕太阳的时间大约 365天，这不是我们的错，绕地球月球的轨道是大约27.3天（取决于我们是否在谈论一个恒星，朔望，热带，不规则，或龙脉（节日）月）。
你不是很高兴，日历没有采取所有这些细节考虑在内？那么我们的软件错误可能确实取决于月球的相位。
是不是第一行总是浪费时间？你从cal得到一个Date到Calendar.getTime（），那么为什么要用新的Date（）调用创建一个然后抛弃呢？特别是如果你是基准这... – unwind 2009-01-20 08:35:01
@ unwind：一个很好的捕获。为什么不呢，发个帖子。 – 2009-01-20 09:01:59
也许是因为美国人平均预期日期（年整型，诠释天，月整型）;-) – Skizz 2009-01-20 09:55:50