Почему большинство методов java.util.Date устарели?

Question

Когда вы смотрите на javadoc класса java.util.Date, большинство методов устарели. Почему это было сделано?

Answer 1

Ну, по двум связанным причинам. Это была очень плохая реализация концепции Даты и Времени, и она была заменена классом Calendar.

Класс Calendar, хотя и является улучшением, также оставляет желать лучшего, поэтому для серьезной работы с датой и временем все рекомендуют Joda-Time . Java 8 приносит новый java.time. * Пакет , вдохновленный Joda-Time, определяемый JSR-310 и предназначенный для замены старой даты / Календарь занятий.

Редактировать: В ответ на конкретный вопрос о том, почему реализация плохая, есть много причин. JavaDoc резюмирует это следующим образом:

К сожалению, API для этих функций не поддается интернационализации.

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

Calendar имеет свои проблемы, но даже в JDK 1.1 было очевидно, что java.util.Date не собирается его сокращать. Несмотря на то, что Calendar является спорным худшим JDK API, потребовалось до версии 7, чтобы попытаться решить эту проблему.

Answer 2

• Date является изменяемым
• Date не поддерживает часовые пояса

Последнее привело к его замене на Calendar. И первое, в сочетании с простотой использования, приводит к замене обоих на Joda-Time / JSR-310 ( java.time. * Package * 1015) *)

Answer 3

Они устарели, потому что Дата была написана как можно быстрее в тот день, когда они хотели вырвать JDK за дверь.

Оказывается, даты и календари сложны. Итак, они создали класс Calendar, о котором гораздо больше думали, чтобы справляться с трудными деталями работы с календарями.

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

Answer 4

Вот хороший ответ прямо из Oracle: http://www.oracle.com/technetwork/articles/java/jf14-date-time-2125367.html

Давным багбером разработчиков Java была недостаточная поддержка случаев использования даты и времени обычных разработчиков.

Например, существующие классы (такие как java.util.Date и SimpleDateFormatter) не являются поточно-ориентированными, что приводит к потенциальным проблемам параллелизма для пользователей - не то, с чем среднестатистический разработчик мог бы столкнуться при написании обработки дат код.

Некоторые классы даты и времени также демонстрируют довольно плохой дизайн API. Например, годы в java.util.Date начинаются с 1900 года, месяцы начинаются с 1, а дни начинаются с 0 - не очень интуитивно.

... java.util.Date представляет момент времени на временной шкале - обертку вокруг количества миллисекунд с начала UNIX - но если вы вызываете toString (), результат предполагает, что у него есть часовой пояс, что вызывает путаницу среди разработчиков.

Answer 5

Я не знаю официальной причины, по которой он устарел, но, насколько я могу судить, GregorianCalendar и Joda-Time поддерживают операции с датами, то есть, например, вы можете добавить , день до даты и соответственно обновляет месяц и год.

Например, скажем, вы хотите вычислить день после текущей даты, а сегодня 31 мая; с java.util.Date у вас просто есть getDays() +1, который возвращает 32, и вы должны понимать, что в текущем месяце нет 32 дней самостоятельно; с GregorianCalendar или Joda.time, добавление дня к 31 мая приводит к объекту, представляющему 1 июня, скрывая сложность от вашего взгляда.