为什么“new Date(intyear,intmonth,intday)”是 已弃用？
我最近继承的应用程序充满了关于构造函数的弃用警告：
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% 的时间来执行。
My application I've recently inherited is FULL of deprecation warnings about the constructor:
Date d = new Date(int year, int month, int day)
Does anyone know or can point to a reason why something as simple as this was "replaced" with something like this:
Date d = null;
Calendar cal = GregorianCalendar.getInstance();
cal.set(1900 + year, month, day);
d = cal.getTime();
Now, obviously deprecation warnings are not a problem in themselves, but can you imagine the millions of LOC that would be crying out in agony if this constructor was ever removed?
In my brief little play at benchmarking, the latter takes about 50% more time to execute.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
最初，
Date旨在包含有关日期的所有逻辑，但 API 设计者最终意识到，他们迄今为止所拥有的 API 严重不足，无法干净地扩展以正确处理时区等问题， 因此，他们创建了
Calendar来处理所有这些复杂性，并将Date降级为简单的时间戳，弃用了其处理所有问题的功能具有格式化、解析和单独的日期字段。顺便说一句，在内部，这些方法（例如
Date(int, int, int)构造函数）现在调用Calendar，因此，如果您发现速度存在差异，那么您就做错了什么调用日历时。底线：Java 的
CalendarAPI 并不是过于复杂，而是人类对日期的概念，Calendar的唯一问题是它提供的方式不多。最常见用法的快捷方式。Originally,
Datewas intended to contain all logic concerning dates, but the API designers eventually realized that the API they had so far was woefully inadequate and could not be cleanly extended to deal correctly with issues such as timezones, locales, different calendars, daylight savings times, etc.So they created
Calendarto deal with all that complexity, and relegatedDateto a simple timestamp, deprecating all its functionality that dealt with formatting, parsing and individual date fields.BTW, internally these methods such as
Date(int, int, int)constructor now callCalendar, so if you see a difference in speed, then you're doing something wrong when callingCalendar.The bottomline: It's not Java's
CalendarAPI that is overly complex, it's the human concept of dates, and the only problem withCalendaris that it offers not much in the way of shortcuts to the most common usages.Java Date API 长期以来一直受到批评，例如参见
您可能想查看 Joda-Time 或 Apache Commons Lang 用于替代日期/时间实用程序。
The Java Date APIs have long been critized, see for instance this thread.
You might want to check out Joda-Time or Apache Commons Lang for alternative Date/Time utilities.
答案是便携性。
Date类不太灵活。 您可以定义日期，但不能转换为其他日历格式。 因此，Sun 决定使用额外的类层次结构 (Calendar) 来使其更加灵活。尽管如此，它并不是很方便。
The answer is portability.
The class
Dateis not very flexible. You can define dates, but not with any transformation into other calendar formats. So Sun decided to use an additional class hierarchy (Calendar) to make it more flexible.Nonetheless, it's not very handy.
主要是因为原始的 java.util.Date 臃肿并且不完全了解时区并且不国际化友好。
然而，日期仍在使用，并且在值对象中使用得很好，或者说作为一种数据类型。 只要你明确地使其不可变，你就可以轻松地进行。 我倾向于认为它必须是不可变的，出于其他目的，我们可以操纵日历。 如果需要大量的操作，人们应该考虑像 Joda-Time 这样的东西。
[已编辑]
只是不要在后面的代码中实例化日期。 其无用处。 您可能会获得更好的基准测试结果。
Mostly because the original java.util.Date was bloated and not completely timezone aware and not internationalization friendly.
However, Date is still in use and very well, in Value Objects, or say as a data type. As far as you make it immutable explicitly, you can go with ease. I tend to think it must be immutable, for other purpose we have Calendar to manipulate. Where its lot of manipulation expected, one should consider something like, Joda-Time.
[Edited]
Just don't instantiate the Date, in the latter code. Its of no use. You may achieve a better result for your benchmark.
从技术上讲，迈克尔·博格沃特给出了最好的答案。
但他为什么要把太阳系的布局归咎于人类呢？
好的，我们想出了秒、分钟和小时的想法。
但这并不是我们的错，地球日是近似的（取决于我们谈论的是真太阳日、平太阳日还是恒星日，其中每一个都会周期性地随机变化）。 地球绕太阳公转的时间大约 365 天，这不是我们的错；月球绕地球公转的时间大约 27.3 天，也不是我们的错（取决于我们谈论的是恒星月、朔望月、热带月、异常月还是龙月（交点月））。
您是否很高兴日历没有考虑所有这些细节？ 那么我们的软件错误可能确实取决于月相。
Michael Borgwardt had the best answer, technically.
But why is he blaming humans for the way our solar system is laid out?
OK, we came up with the idea of seconds, and minutes, and hours.
But it's not our fault that that Earth's day is approximate (depending on whether we're talking about true solar day, mean solar day, or stellar day, each of which varies periodically and randomly). It isn't our fault that the time of Earth's orbit around the Sun is approximately 365 days, and it's not our fault that the moon's orbit around the Earth is approximately 27.3 days (depending on whether we're talking about a sidereal, synodic, tropical, anomalistic, or draconic (nodical) month).
Aren't you glad that Calendar didn't take all those details into account? Then our software bugs might indeed be dependent on the phase of the moon.
当然，没有人使用任何其他日历格式，但新的 API 增加了 99% 常见情况所需编写的代码量，因此对于 LoC 付费的 Java 程序员来说是一个巨大的福音。
Of course, no-one ever uses any other calendar format, but the new API increases the amount of code to write for the 99% common case, so it's a great boon for Java programmers paid by LoC.