为什么Java日期API（java.util.Date，.Calendar）这么混乱？ [英] Why is the Java date API (java.util.Date, .Calendar) such a mess?

问题描述

由于大多数人现在痛苦地意识到，用于处理日历日期的Java API（特别是类 java.util.Date 和 java .util.Calendar ）是一个可怕的混乱。

我的头顶：

• 日期是可变的


• 日期代表时间戳，而不是日期


• 日期组件（日，月，年...）和日期


• 日历笨重使用，并尝试将不同的日历系统组合成一个类

这篇文章总结相当不错， JSR-310 也使这些问题出现。

现在我的问题是：

这些类如何使它们进入Java SDK？大多数这些问题似乎很明显（特别是日期是可变的），应该很容易避免。那怎么了呢？时间压力？或者是仅仅在回顾中显而易见的问题？

我意识到这不是一个严格的编程问题，但我会发现有趣的是了解API设计可能如此错。毕竟，错误总是一个很好的学习机会（我很好奇）。

解决方案

有人把它比我可以曾经说过：

• Class Date 具体时间，毫秒
  精度。这个课程的设计是一个非常糟糕的笑话 - 一个清醒的
  的例子，甚至好的程序员搞砸了。
  Date中的大多数方法现在已被弃用，由以下类中的方法替代。



• 类日历是一个用于在 Date
  对象和一组整数字段（如年，月，日和小时）之间进行转换的抽象类。

  / li>
  

• 类 GregorianCalendar 是JDK中 Calendar 的唯一子类。
  通常使用
  中的日历系统的日期到字段转换。 Sun授权这个来自Taligent的这种加强的垃圾 - 一个
  令人清醒的例子，说明平均程序员如何解决。

从Java程序员常见问题解答，从07.X.1998版本的Peter van der Linden版本 - 这部分已经从以后的版本中删除了。

对于可变性，很多早期的JDK类受苦（ Point ， Rectangle ，尺寸，...）。错误的优化，我听到有人说。

想法是想要重用对象（ o.getPosition（）。 x + = 5 ）而不是创建副本（ o.setPosition（o.getPosition（）。add（5，0）））与immutables有关。这可能是早期虚拟机的一个好主意，而最有可能不是现代虚拟机。

As most people are painfully aware of by now, the Java API for handling calendar dates (specifically the classes java.util.Date and java.util.Calendar) are a terrible mess.

Off the top of my head:

• Date is mutable
• Date represents a timestamp, not a date
• no easy way to convert between date components (day, month, year...) and Date
• Calendar is clunky to use, and tries to combine different calendar systems into one class

This post sums it up quite well, and JSR-310 also expains these problems.

Now my question is:

How did these classes make it into the Java SDK? Most of these problems seem fairly obvious (especially Date being mutable) and should have been easy to avoid. So how did it happen? Time pressure? Or are the problems obvious in retrospect only?

I realize this is not strictly a programming question, but I'd find it interesting to understand how API design could go so wrong. After all, mistakes are always a good learning opportunity (and I'm curious).

解决方案

Someone put it better than I could ever say it:

• Class Date represents a specific instant in time, with millisecond precision. The design of this class is a very bad joke - a sobering example of how even good programmers screw up. Most of the methods in Date are now deprecated, replaced by methods in the classes below.

• Class Calendar is an abstract class for converting between a Date object and a set of integer fields such as year, month, day, and hour.

• Class GregorianCalendar is the only subclass of Calendar in the JDK. It does the Date-to-fields conversions for the calendar system in common use. Sun licensed this overengineered junk from Taligent - a sobering example of how average programmers screw up.

from Java Programmers FAQ, version from 07.X.1998, by Peter van der Linden - this part was removed from later versions though.

As for mutability, a lot of the early JDK classes suffer from it (Point, Rectangle, Dimension, ...). Misdirected optimizations, I've heard some say.

The idea is that you want to be able to reuse objects (o.getPosition().x += 5) rather than creating copies (o.setPosition(o.getPosition().add(5, 0))) as you have to do with immutables. This may even have been a good idea with the early VMs, while it's most likely isn't with modern VMs.

这篇关于为什么Java日期API（java.util.Date，.Calendar）这么混乱？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！