Java 8 Date API vs Calendar/Date/DateFormat

Этот новый API-интерфейс Date-n-cool в Java 8, java.time package. Я понимаю, что он лучше разработан, менее двусмыслен и более потокобезопасен, чем старые классы. Тем не менее, я не уверен, как его использовать:

  • Следует ли использовать его исключительно вместо старых классов?
  • Должен ли я заменить существующие обычаи старых классов, если я их увижу, потому что новый материал намного лучше?
  • Должен ли я воздерживаться от использования java.util.Calendar, java.util.Date, java.sql.Date и java.text.DateFormat в пользу нового API вместе или существуют ли случаи использования , где старые классы по-прежнему предпочтительнее?
  • Был ли API Joda Time API устаревшим благодаря новому API Date аналогично замене Guava FluentIterable API Java 8 stream?

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

Ответ 1

Должен ли я использовать его исключительно вместо старых классов?

Нет, не нужно исключать старые классы. Старый java.util.Date/.Calendar работает одинаково, без изменений. Они не устарели.

Вы можете смешивать и сопоставлять все три фреймворка (старые классы, Joda-Time и java.time). Просто будьте осторожны с некоторыми идентичными или похожими именами классов - смотрите инструкции import!

См. Учебное пособие, Legacy Date-Time Code.

Кроме того, проект ThreeTen-Extra расширяет java.time с дополнительными функциями. "ThreeTen" относится к JSR 310, который определяет java.time.

Должен ли я заменить существующие обычаи старых классов, если я их увижу, потому что новый материал намного лучше?

Если старый код работает так, как предполагалось, то теперь не нужно менять.

Если вы обеспокоены тем, что старый код, возможно, неправильно обрабатывает часовые пояса или хочет сделать больше локализации, вы можете переработать их с помощью java.time. Даже тогда помните, что вы можете легко конвертировать между j.u.Date и Instant. Таким образом, вы можете оставить свою бизнес-логику как есть с помощью j.u.Date/.Calendar и изменить только код пользовательской презентации, чтобы использовать java.time.

Должен ли я воздерживаться от использования java.util.Calendar, java.util.Date, java.sql.Date и java.text.DateFormat в пользу нового API все вместе или существуют случаи, когда старые классы все еще остаются предпочтительнее?

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

Новые классы java.time намного превосходят, поэтому их добавили. И они более логичны и проще в использовании. Так что да, было бы полезно и приятно научиться их использовать. Но не срочно. В хрусте напишите код старым способом, к которому вы привыкли. Когда вы можете позволить себе время учиться (Tutorial), а для выполнения дополнительного тестирования начните использовать новые классы.

Разработчик новичка обязательно должен сосредоточить свое обучение на java.time.

Был ли API-интерфейс Joda Time устаревшим благодаря новому API Date аналогично замене Guava FluentIterable на Java 8 stream API?

Joda-Time было вдохновением для java.time. Те же люди изобрели оба. Они предполагают, что java.time станет их "2.0" повторным изобретением Joda-Time, что бы они сделали, если бы знали, что они знают сейчас. Они сказали, что пользователи Joda-Time должны перейти на java.time.

Тем не менее, Йода-Время не уходит. Он по-прежнему работает, по-прежнему обновляется с исправлениями ошибок и свежими данными о часовых поясах tz. И это очень важно для большого сообщества Android, у которого нет другой подходящей библиотеки времени (я знаю). Таким образом, вы можете продолжать полагаться на Joda-Time, не нужно срочно копировать старый код, но не ожидайте новых функций или улучшений.

Joda-Time хорошо изношен и проверен, в то время как у java.time было несколько мелких ошибок и перегибов. Joda-Time и java.time имеют функции других недостатков. Так что лично, я смешиваю-и-матч, чтобы наилучшим образом соответствовать. Я полагаюсь на Joda-Time, занимаясь java.time.

Планировать возможный переход на java.time, но не спешить, не панику.