Почему" новая дата(int год, int месяц, int день) " устарела?


мое приложение, которое я недавно унаследовал, полно предупреждений об устаревании конструктора:

Date d = new Date(int year, int month, int day)

кто-нибудь знает или может указать на причину, почему что-то столь простое, как это было "заменено" чем-то вроде этого:

Date d = null;
Calendar cal = GregorianCalendar.getInstance();
cal.set(1900 + year, month, day);
d = cal.getTime();

теперь, очевидно, что предупреждения об устаревании сами по себе не являются проблемой, но вы можете себе представить миллионы LOC, которые будут кричать в агонии, если этот конструктор когда-либо будет удален?

в моей короткой маленькой пьесе при бенчмаркинге выполнение последнего занимает примерно на 50% больше времени.

6   58   2009-01-20 11:04:23

6 ответов:

изначально Date предназначалось для того, чтобы содержать всю логику относительно дат, но разработчики API в конечном итоге поняли, что API, который они имели до сих пор, был прискорбно неадекватным и не мог быть чисто расширен, чтобы правильно решать такие вопросы, как часовые пояса, локали, различные календари, летнее время и т. д.

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

кстати, внутренне эти методы, такие как Date(int, int, int) сейчас вызов конструктора Calendar, Так что если вы видите разницу в скорости, то вы делаете что-то неправильно при вызове Calendar.

нижняя линия: это не Java Calendar API, который слишком сложен, это человеческая концепция дат, и единственная проблема с Calendar это то, что он предлагает не так много на пути ярлыков для наиболее распространенных обычаев.

API Java Date уже давно критикуются, см. например этой теме.

вы, возможно, захотите, чтобы проверить Joda Времени или Apache Commons Lang для альтернативных утилит даты и времени.

ответ переносимости.

класс Date не очень гибкий. Вы можете определить даты, но не с любым преобразованием в другие форматы календаря. Поэтому Sun решила использовать дополнительную иерархию классов (Calendar), чтобы сделать его более гибким.

тем не менее, это не очень удобно.

в основном потому, что исходная java.утиль.Дата была раздута и не полностью часовой пояс в курсе и не интернационализация дружественных.

однако дата все еще используется и очень хорошо, в объектах Value или, скажем, в качестве типа данных. Поскольку вы делаете его неизменным явно, вы можете пойти с легкостью. Я склонен думать, что он должен быть неизменным, для другой цели у нас есть календарь, чтобы манипулировать. Где его много манипуляций ожидается, следует рассмотреть что-то вроде, Джода-Время.

[отредактировано]

просто не создавайте экземпляр даты в последнем коде. Это бесполезно. Вы можете достичь лучшего результата для вашего бенчмарка.

конечно, никто никогда не использует какой-либо другой формат календаря, но новый API увеличивает количество кода для написания для 99% общего случая, поэтому это большое благо для Java-программистов, оплачиваемых LoC.

Майкл Borgwardt был лучший ответ, технически. Но почему он обвиняет людей в том, как устроена наша Солнечная система?

хорошо, мы придумали идею секунд, минут и часов.

примерно 365 дней, и это не наша вина, что орбита Луны вокруг Земли примерно 27,3 дня (в зависимости от того, идет ли речь о звездном, синодическом, тропическом, аномальном или Драконьем (узловом) месяце).

разве вы не рады, что календарь не учел все эти детали? Тогда наши программные ошибки действительно могут зависеть от фазы Луны.