为什么Java日期API(java.util.Date,.Calendar)如此混乱?

内容来源于 Stack Overflow,并遵循CC BY-SA 3.0许可协议进行翻译与使用

  • 回答 (2)
  • 关注 (0)
  • 查看 (21)

由于大多数人现在都痛苦地意识到,用于处理日历日期(特别是类java.util.Datejava.util.Calendar)的Java API 是一团糟。

离开我的头顶:

  • 日期是可变的
  • 日期代表时间戳,而不是日期
  • 在日期组件(日,月,年...)和日期之间进行转换没有简单的方法
  • 日历笨重使用,并尝试将不同的日历系统合并到一个类中

这篇文章总结得非常好,JSR-310也解决了这些问题。

现在我的问题是:

这些类是如何进入Java SDK的?这些问题中的大部分看起来相当明显(特别是Date可变),应该很容易避免。那么它是如何发生的?时间压力?还是只是回顾过去的问题显而易见?

我意识到这不是一个严格的编程问题,但是我会发现理解API设计如何错误是很有趣的。毕竟,错误总是一个很好的学习机会(我很好奇)。

提问于
用户回答回答于

有人把它说得比我以前说的更好:

  • Date代表一个特定的时刻,具有毫秒级的精度。这门课的设计是一个非常糟糕的玩笑 - 一个甚至是好程序员都搞不清的例子。Date中的大多数方法现在已被弃用,被下面的类中的方法所取代。
  • Calendar是一个抽象类,用于在Date 对象和一组整数字段(如年,月,日和小时)之间进行转换。
  • Class GregorianCalendarCalendarJDK中唯一的子类。它为常用日历系统进行日期到字段的转换。Sun从Taligent那里获得了这个过度工程垃圾的许可 - 这是一个普通程序员如何搞砸的清醒例子。

来自Peter van der Linden的Java程序员常见问题解答,版本由07.X.1998开始 - 尽管如此,这部分内容已从后续版本中删除。

至于可变性,很多早期的JDK类的遭受它(PointRectangleDimension,...)。错误的优化,我听到了一些说法。

这个想法是,您希望能够重用对象(o.getPosition().x += 5),而不是像创建o.setPosition(o.getPosition().add(5, 0))不可变对象那样创建副本()。对于早期的虚拟机来说,这甚至可能是一个好主意,但最有可能的不是现代虚拟机。

用户回答回答于

Java的早期API只不过是他们时代的产物。在此之后的几年里,不变性才成为流行的概念。你说不变性是“显而易见的”。现在可能是这样,但事实并非如此。就像依赖注入现在“显而易见”,但它不是10年前。

创建Calendar对象的时间也很昂贵。

为了向后兼容的原因,它们仍然如此。可能更不幸的是,一旦发现错误,旧类别不会被弃用,并且所有API的未来都会创建新的日期/时间类别。这在一定程度上发生在JDK 8采用类似API的JodaTime(java.timeJSR 310)之后,但实际上这太迟了。

扫码关注云+社区