为什么 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 类)真是一团糟.

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.

我的头顶:

• 日期是可变的
• Date 代表时间戳，而不是日期
• 没有简单的方法可以在日期组件(日、月、年...)和日期之间进行转换
• Calendar 使用起来很笨拙，并试图将不同的日历系统合并为一个类

这篇文章 总结得很好，JSR-310 也解释了这些问题.

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

现在我的问题是:

这些类是如何进入 Java SDK 的?大多数这些问题似乎相当明显(尤其是 Date 是可变的)并且应该很容易避免.那么它是如何发生的呢?时间压力?还是只是回想起来问题很明显?

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?

我意识到这不是严格的编程问题，但我觉得了解 API 设计如何出错很有趣.毕竟，错误总是一个很好的学习机会(我很好奇).

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).

推荐答案

有人说得比我说得好:

• Class Date 代表一个特定的时刻，以毫秒为单位精确.这个班级的设计是一个非常糟糕的笑话——一个发人深省的即使是优秀的程序员也是如何搞砸的例子.大多数方法在日期现已弃用，取而代之的是以下类中的方法.

• Class Calendar 是一个抽象类，用于在 Date 之间进行转换对象和一组整数字段，例如年、月、日和小时.

• 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 是 JDK 中 Calendar 的唯一子类.它在日历系统中执行日期到字段的转换常用.Sun 从 Taligent 授权了这种过度设计的垃圾——一个普通程序员如何搞砸的发人深省的例子.

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.

来自 Java Programmers FAQ，版本自 07.X.1998，作者 Peter van der Linden - 不过这部分已从更高版本中删除.

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

至于可变性，许多早期的 JDK 类都受到它的影响(Point、Rectangle、Dimension、...).误导的优化，我听到有人说.

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

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

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屋！