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

Как большинство людей уже прекрасно осознают, Java API для обработки календарных дат (в частности, классов java.util.Date и java.util.Calendar) представляют собой ужасный беспорядок.

У меня в голове не укладывается:

• Дата изменчива


• Дата представляет собой временную метку, а не дату


• нет простого способа преобразовать компоненты даты (день, месяц, год ...) в Date


• Calendar неудобен в использовании и пытается объединить разные календарные системы в один класс

Этот пост (мертвая ссылка - ссылка на архив) довольно хорошо подводит итог, и JSR-310 также устраняет эти проблемы.

Теперь мой вопрос таков:

Как эти классы попали в Java SDK? Большинство этих проблем кажутся довольно очевидными (особенно изменяемая дата), и их должно было быть легко избежать. Так как же это произошло? Нехватка времени? Или проблемы очевидны только в ретроспективе?

Я понимаю, что это не вопрос строго программирования, но мне было бы интересно понять, как дизайн API мог пойти так неправильно. В конце концов, ошибки - это всегда хорошая возможность для обучения (и мне любопытно).

Кто-то выразил это лучше, чем я когда-либо мог бы сказать:

• Класс Date представляет определенный момент времени с точностью до миллисекунды. Дизайн этого класса - очень плохая шутка - отрезвляющий пример того, как облажаются даже хорошие программисты. Большинство методов в Date теперь устарели, их заменили методами из приведенных ниже классов.



• Class Calendar - это абстрактный класс для преобразования между Date объектом и набором целочисленных полей, таких как год, месяц, день и час.




• Класс GregorianCalendar является единственным подклассом Calendar в JDK. Он выполняет преобразования даты в поля для широко используемой календарной системы. Sun лицензировала этот переработанный мусор от Taligent - отрезвляющий пример того, как облажаются обычные программисты.

из Часто задаваемых вопросов Java-программистов, версия от 07.X.1998, автор Питер ван дер Линден - эта часть была удалена из более поздних версий.

Что касается изменчивости, многие ранние классы JDK страдают от этого (Point, Rectangle, Dimension, ...). Я слышал, что некоторые говорят о неправильной оптимизации.

Идея в том, что вы хотите иметь возможность повторно использовать объекты (o.getPosition().x += 5), а не создавать копии (o.setPosition(o.getPosition().add(5, 0))), как вы должны делать с неизменяемыми. Возможно, это даже было хорошей идеей для ранних виртуальных машин, в то время как для современных виртуальных машин, скорее всего, нет.

Ранние API Java - не более чем продукт своего времени. Неизменяемость стала популярной концепцией только спустя годы после этого. Вы говорите, что неизменяемость "очевидна". Это могло бы быть правдой сейчас, но не тогда. Точно так же, как внедрение зависимостей сейчас "очевидно", но этого не было 10 лет назад.

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 (java.time, JSR 310) but really it's too little too late.

Time is itself not easy to measure and to handle with. Just look at the length of the wikipedia article about time. 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.?)