为什么Java date API (java.util.Date、.Calendar)如此混乱？
到目前为止，大多数人都痛苦地意识到，用于处理日历日期的Java API (特别是java.util.Date和java.util.Calendar类)非常混乱。
在我的脑海中：
- Date is mutable
- Date代表一个时间戳，而不是一个日期
- 没有简单的方法在日期组件(日、月、年...)之间进行转换Date
- Calendar使用起来很笨拙，它试图将不同的日历系统合并到一个类
中
This post很好地总结了这一点，JSR-310也解释了这些问题。
现在我的问题是：
这些类是如何进入Java SDK的呢？这些问题中的大多数似乎都相当明显(特别是Date是可变的)，应该很容易避免。那么这是怎么发生的呢？时间压力？或者，这些问题只是在回顾中显而易见吗？
我意识到这不是一个严格意义上的编程问题，但我发现理解API设计怎么会出错是一件很有趣的事情。毕竟，错误总是一个很好的学习机会(我很好奇)。
回答 4
Stack Overflow用户
发布于 2009-10-15 09:45:43
有人说得比我说的更好：
- 类
Date表示时间上的特定瞬间，精度为毫秒。这个类的设计是一个非常糟糕的笑话--一个发人深省的例子，说明即使是优秀的程序员也会搞砸。Date中的大多数方法现已弃用，取而代之的是以下类中的方法。 - 类
Calendar是一个抽象类，用于在Date对象和一组整数字段(如年、月、日和小时)之间进行转换。 - 类
GregorianCalendar是Calendar的唯一子类。它为常用的日历系统执行日期到字段的转换。Sun从Taligent获得了这个过度设计的垃圾软件的许可--这是一个发人深省的例子，说明了普通程序员是如何搞砸的。
来自Java程序员常见问题解答，版本从1998年7月7日开始，由Peter van der Linden撰写--这一部分已从以后的版本中删除。
至于可变性，很多早期的JDK类(Point、Rectangle、Dimension等)都受到了它的影响。我听到一些人说，优化被误导了。
其思想是，您希望能够重用对象(o.getPosition().x += 5)，而不是像处理不可变对象那样创建副本(o.setPosition(o.getPosition().add(5, 0)))。对于早期的VM，这可能是一个好主意，而对于现代VM来说，这很可能不是一个好主意。
Stack Overflow用户
发布于 2009-10-15 09:41:16
Java早期的API只不过是他们那个时代的产物。在那之后几年，不变性才成为一个流行的概念。你说不变性是“显而易见的”。现在这可能是真的，但那时候不是。就像依赖注入现在是“显而易见的”，但在10年前还不是。
创建Calendar对象的成本也一度很高。
出于向后兼容性的原因，它们仍然是这样的。也许更不幸的是，一旦意识到这个错误，旧的类并没有被弃用，而是为未来的所有API创建了新的日期/时间类。这在某种程度上是由于JDK8采用了类似JodaTime (java.time，JSR310)的API，但实际上这太少了，也太迟了。
Stack Overflow用户
发布于 2009-10-15 11:38:14
时间本身并不容易衡量和处理。只要看看维基百科上关于time的文章的长度就知道了。然后，对时间本身有不同的理解:一个绝对的时间点(作为一个常数)，一个特定地点的时间点，一个时间范围，时间的分辨率……
我记得，当我第一次看到java.util.Date时(JDK1.0？)我对此真的很高兴。我所知道的语言没有这样的特性。我没有考虑时间转换等问题。
我认为这是混乱的，因为如果你从一个层次的理解(XMLGregorianCaldender vs. Date)和需求(纳秒，超过2030年)发展到更高的层次，但保持旧的不变，那么一切变化都会留下一片混乱。java.util.Date也不例外。看看I/O子系统或者从AWT到Swing的转换就知道了……
正因为如此，“我们有时应该按下重置按钮。”(顺便说一句，是谁说的？)
https://stackoverflow.com/questions/1571265
复制相似问题