blocks|key|325788|text|Java早期的API只不过是他们那个时代的产物。在那之后几年，不变性才成为一个流行的概念。你说不变性是“显而易见的”。现在这可能是真的，但那时候不是。就像依赖注入现在是“显而易见的”，但在10年前还不是。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|325789|创建Calendar对象的成本也一度很高。|325790|出于向后兼容性的原因，它们仍然是这样的。也许更不幸的是，一旦意识到这个错误，旧的类并没有被弃用，而是为未来的所有API创建了新的日期/时间类。这在某种程度上是由于JDK8采用了类似JodaTime+(java.time，JSR310)的API，但实际上这太少了，也太迟了。|offset|length|style|CODE|325791|entityMap^0|0|0|2S|9|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|M|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|N|8|@$F|O|G|P|H|I]]|9|@]|A|$]]|$1|J|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|K|$]]

Java's early APIs are nothing more than a product of their time. Immutability only became a popular concept years after that. You say that immutability is "obvious". That might be true now but it wasn't then. Just like dependency injection is now "obvious" but it wasn't 10 years ago.

It was also at one time expensive to create Calendar objects.

They remain that way for backwards compatibility reasons. What is perhaps more unfortunate was that once the mistake was realized the old class wasn't deprecated and new date/time classes were created for all APIs going forward. This has to some degree occurred with the JDK 8 adoption of a JodaTime like API (<code>java.time</code>, JSR 310) but really it's too little too late.

blocks|key|327485|text|有人说得比我说的更好：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|327486|327487|blockquote|327488|327489|327490|类Date表示时间上的特定瞬间，精度为毫秒。这个类的设计是一个非常糟糕的笑话--一个发人深省的例子，说明即使是优秀的程序员也会搞砸。Date中的大多数方法现已弃用，取而代之的是以下类中的方法。|unordered-list-item|offset|length|style|CODE|327491|类Calendar是一个抽象类，用于在Date对象和一组整数字段(如年、月、日和小时)之间进行转换。|327492|类GregorianCalendar是Calendar的唯一子类。它为常用的日历系统执行日期到字段的转换。Sun从Taligent获得了这个过度设计的垃圾软件的许可--这是一个发人深省的例子，说明了普通程序员是如何搞砸的。|327493|327494|来自Java程序员常见问题解答，版本从1998年7月7日开始，由Peter+van+der+Linden撰写--这一部分已从以后的版本中删除。|327495|至于可变性，很多早期的JDK类(Point、Rectangle、Dimension等)都受到了它的影响。我听到一些人说，优化被误导了。|327496|其思想是，您希望能够重用对象(o.getPosition().x+%2B=+5)，而不是像处理不可变对象那样创建副本(o.setPosition(o.getPosition().add(5,+0)))。对于早期的VM，这可能是一个好主意，而对于现代VM来说，这很可能不是一个好主意。|327497|entityMap^0|0|0|0|0|0|1|4|0|1|8|J|4|0|1|H|J|8|0|0|0|G|5|M|9|W|9|0|F|M|1L|14|0^^$0|@$1|2|3|4|5|6|7|10|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|11|8|@]|9|@]|A|$]]|$1|C|3|-4|5|D|7|12|8|@]|9|@]|A|$]]|$1|E|3|-4|5|6|7|13|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|14|8|@]|9|@]|A|$]]|$1|G|3|H|5|I|7|15|8|@$J|16|K|17|L|M]]|9|@]|A|$]]|$1|N|3|O|5|I|7|18|8|@$J|19|K|1A|L|M]|$J|1B|K|1C|L|M]]|9|@]|A|$]]|$1|P|3|Q|5|I|7|1D|8|@$J|1E|K|1F|L|M]|$J|1G|K|1H|L|M]]|9|@]|A|$]]|$1|R|3|-4|5|6|7|1I|8|@]|9|@]|A|$]]|$1|S|3|T|5|6|7|1J|8|@]|9|@]|A|$]]|$1|U|3|V|5|6|7|1K|8|@$J|1L|K|1M|L|M]|$J|1N|K|1O|L|M]|$J|1P|K|1Q|L|M]]|9|@]|A|$]]|$1|W|3|X|5|6|7|1R|8|@$J|1S|K|1T|L|M]|$J|1U|K|1V|L|M]]|9|@]|A|$]]|$1|Y|3|-4|5|6|7|1W|8|@]|9|@]|A|$]]]|Z|$]]

Someone put it better than I could ever say it:

<blockquote>
 <ul>
 <li>Class <code>Date</code> 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.</li>
 <li>Class <code>Calendar</code> is an abstract class for converting between a <code>Date</code>
 object and a set of integer fields such as year, month, day, and hour.</li>
 <li>Class <code>GregorianCalendar</code> is the only subclass of <code>Calendar</code> 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.</li>
 </ul>
</blockquote>

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 (<code>Point</code>, <code>Rectangle</code>, <code>Dimension</code>, ...). Misdirected optimizations, I've heard some say.

The idea is that you want to be able to reuse objects (<code>o.getPosition().x += 5</code>) rather than creating copies (<code>o.setPosition(o.getPosition().add(5, 0))</code>) 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.

blocks|key|328454|text|时间本身并不容易衡量和处理。只要看看维基百科上关于time的文章的长度就知道了。然后，对时间本身有不同的理解:一个绝对的时间点(作为一个常数)，一个特定地点的时间点，一个时间范围，时间的分辨率……|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|328455|我记得，当我第一次看到java.util.Date时(JDK1.0？)我对此真的很高兴。我所知道的语言没有这样的特性。我没有考虑时间转换等问题。|328456|我认为这是混乱的，因为如果你从一个层次的理解(XMLGregorianCaldender+vs.+Date)和需求(纳秒，超过2030年)发展到更高的层次，但保持旧的不变，那么一切变化都会留下一片混乱。java.util.Date也不例外。看看I/O子系统或者从AWT到Swing的转换就知道了……|328457|正因为如此，“我们有时应该按下重置按钮。”(顺便说一句，是谁说的？)|328458|entityMap|0|LINK|mutability|MUTABLE|url|http://en.wikipedia.org/wiki/Time^0|P|4|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|R|8|@]|9|@$A|S|B|T|1|U]]|C|$]]|$1|D|3|E|5|6|7|V|8|@]|9|@]|C|$]]|$1|F|3|G|5|6|7|W|8|@]|9|@]|C|$]]|$1|H|3|I|5|6|7|X|8|@]|9|@]|C|$]]|$1|J|3|-4|5|6|7|Y|8|@]|9|@]|C|$]]]|K|$L|$5|M|N|O|C|$P|Q]]]]

Time is itself not easy to measure and to handle with. Just look at the length of the wikipedia article about <a href="http://en.wikipedia.org/wiki/Time" rel="noreferrer">time</a>. And then, there are different understandings about time itself: a absoulte time point (as a constant), a time point at a certain place, a time range, the resolution of time....

I remember, when i saw java.util.Date the first time (JDK 1.0?) i was really happy about it. The languages i knew of didn't had such a feature. I didn't have think about time conversion etc.

I think it's mess, because everything that changes leaves a mess if you evolve from one level of understanding (XMLGregorianCaldender vs. Date) and requirements (Nanoseconds, past 2030) to higher level, but keeping the old untouched. And java.util.Date is not a Exception. Just look at the I/O subsystem or the transition from AWT to Swing...

And because of that, "we should sometimes press the reset button." (who said that, btw.?)

blocks|key|325858|text|你可能会发现下面的帖子很有趣。它很好地解释了Calendar类最初是如何进入Java+API的，并揭示了date类的起源。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|325859|The+Seven+Habits+of+Highly+Dysfunctional+Design|offset|length|325860|entityMap|0|LINK|mutability|MUTABLE|url|http://www.jroller.com/cpurdy/entry/the_seven_habits_of_highly^0|0|0|1B|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|O|8|@]|9|@$D|P|E|Q|1|R]]|A|$]]|$1|F|3|-4|5|6|7|S|8|@]|9|@]|A|$]]]|G|$H|$5|I|J|K|A|$L|M]]]]

You might find the following post interesting. It pretty much explains how the Calendar class got into the Java API in the first place, and sheds some light on the origins of the date class.

<a href="http://www.jroller.com/cpurdy/entry/the_seven_habits_of_highly">The Seven Habits of Highly Dysfunctional Design</a>

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

Off the top of my head:

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

<a href="http://www.jroller.com/cpurdy/entry/the_seven_habits_of_highly" rel="noreferrer">This post</a> sums it up quite well, and <a href="http://jcp.org/en/jsr/detail?id=310" rel="noreferrer">JSR-310</a> 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).

Why is the Java date API (java.util.Date, .Calendar) such a mess?

Java

到目前为止，大多数人都痛苦地意识到，用于处理日历日期的Java API (特别是java.util.Date和java.util.Calendar类)非常混乱。在我的脑海中：Date is mutableDate代表一个时间戳，而不是一个日期没有简单的方法在日期组件(日、月、年...)之间进行转换DateCalenda...

问为什么Java date API (java.util.Date、.Calendar)如此混乱？
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问为什么Java date API (java.util.Date、.Calendar)如此混乱？EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问为什么Java date API (java.util.Date、.Calendar)如此混乱？
EN