Почему "новая дата (int year, int month, int day)" устарела?

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

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% больше времени для выполнения.

Ответ 1

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

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

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

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

Ответ 2

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

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

Ответ 3

Ответ - переносимость.

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

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

Ответ 4

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

Тем не менее, дата все еще используется и очень хорошо, в объектах Value, или указывается как тип данных. Насколько вы можете сделать это неизменным явным образом, вы можете легко. Я склонен думать, что это должно быть неизменным, для других целей у нас есть календарь для манипулирования. Там, где ожидалось много манипуляций, нужно подумать о чем-то вроде Joda-Time.

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

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

Ответ 5

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

Ответ 6

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

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

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

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