it-swarm.com.ru

Различия между Java 8 API Date Time (Java.time) и Joda-Time

Я знаю, что есть вопросы, касающиеся Java.util.Date и Joda-Time. Но после некоторого поиска я не смог найти нить о различиях между Java.time API (новое в Java 8 , определенное JSR 31 ) и Joda-Time .

Я слышал, что API Java.time в Java 8 намного чище и может делать гораздо больше, чем Joda-Time. Но я не могу найти примеры, сравнивающие два.

  • Что может сделать Java.time, чего не может Joda-Time?
  • Что может сделать Java.time лучше, чем Joda-Time?
  • Производительность лучше с Java.time?
244
Zack

Общие черты

а) Обе библиотеки используют неизменяемые типы. Joda-Time также предлагает дополнительные изменяемые типы, такие как MutableDateTime.

б) Более того: обе библиотеки вдохновлены исследованием дизайна "TimeAndMoney" от Эрика Эванса или идеями Мартин Фаулер о стиле, управляемом доменом , поэтому они более или менее стремятся к - свободный стиль программирования (хотя не всегда идеально ;-)).

c) В обеих библиотеках мы получаем реальный тип календарной даты (называемый LocalDate), реальный тип времени стены (называемый LocalTime) и композицию (называемую LocalDateTime). Это очень большая победа по сравнению со старыми Java.util.Calendar и Java.util.Date.

d) Обе библиотеки используют метод, ориентированный на метод, то есть они поощряют пользователя использовать getDayOfYear() вместо get(DAY_OF_YEAR). Это вызывает много дополнительных методов по сравнению с Java.util.Calendar (хотя последний не является типобезопасным вообще из-за чрезмерного использования целых).

Производительность

Посмотрите другой ответ @ OO7, указывающий на анализ Михаила Воронцова, хотя пункт 3 (отлов исключений), вероятно, устарел - см. этот JDK-баг . Различная производительность (что в целом в пользу JSR-31 ) в основном обусловлена ​​тем фактом, что внутренняя реализация Joda-Time всегда использует машиноподобное время длинный примитив (в миллисекундах).

Null

Joda-Time часто использует NULL по умолчанию для системного часового пояса, языка по умолчанию, текущей метки времени и т.д., В то время как JSR-310 почти всегда отклоняет значения NULL.

Точность

JSR-310 обрабатывает наносекунда точность, в то время как Joda-Time ограничивается миллисекунда точность.

Поддерживаемые поля:

Обзор поддерживаемых полей в Java-8 (JSR-310) дается некоторыми классами во временном пакете (например, ChronoField и WeekFields ), а Joda-Time - довольно слабо в этой области - см. DateTimeFieldType . Самым большим недостатком Joda-Time здесь является отсутствие локализованных недельных полей. Общей особенностью дизайна реализации обоих полей является то, что оба основаны на значениях типа long (никаких других типов, даже перечислений).

Enum

JSR-310 предлагает перечисления подобно DayOfWeek или Month, в то время как Joda-Time не предлагает этого, поскольку он в основном разрабатывался в 2002-2004 годах до Java 5 .

API зоны

а) JSR-310 предлагает больше функций часового пояса, чем Joda-Time. Последние не в состоянии дать программный доступ к истории переходов смещения часового пояса, в то время как JSR-310 способен сделать это.

б) Для вашей информации: JSR-310 переместил свой внутренний репозиторий часовых поясов в новое место и другой формат. Старая папка библиотеки lib/zi больше не существует.

Настройщик против Собственности

JSR-310 представил интерфейс TemporalAdjuster- в качестве формализованного способа экстернализации временных вычислений и манипуляций, особенно для авторов библиотек или фреймворков. Это удобный и относительно простой способ внедрения новых расширений JSR-310 (своего рода эквивалент статического). вспомогательные классы для бывшего Java.util.Date).

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

Joda-Time предлагает полевой пакет, но практика показала, что новые полевые реализации очень трудно кодировать. С другой стороны, Joda-Time предлагает так называемые свойства, которые делают некоторые манипуляции намного проще и элегантнее, чем в JSR-310, например property.withMaximumValue () .

Календарные системы

JSR-310 предлагает 4 дополнительные календарные системы. Наиболее интересным является malqura (используется в Саудовской Аравии). Другие 3: Minguo (Тайвань), японский (только современный календарь с 1871 года!) И ThaiBuddhist (верно только после 1940 года).

Joda-Time предлагает Исламский календарь на основе калькуляционной базы, а не календарь на основе прицела, как Umalqura. Тайский буддист также предлагается Joda-Time в аналогичной форме, Minguo и японский нет. В противном случае Joda-Time также предлагает коптский и эфиопский календарь (но без какой-либо поддержки интернационализации).

Более интересно для европейцев: Joda-Time также предлагает григорианский , юлианский и смешанно-григориано-юлианский календарь. Однако практическое значение для реальных исторических вычислений ограничено, потому что важные функции, такие как разные даты начала года в истории дат, вообще не поддерживаются (такая же критика действительна для старого Java.util.GregorianCalendar).

Другие календари, такие как иврит или персидский или индусский , полностью отсутствуют в обеих библиотеках.

Дни эпохи

JSR-310 имеет класс JulianFields , в то время как Joda-Time (версия 2.0) предлагает некоторые вспомогательные методы в классе DateTimeUtils .

Часы

У JSR-310 нет интерфейса (ошибка проектирования), но есть абстрактный класс Java.time.Clock, который можно использовать для любого внедрения зависимости часов. Вместо этого Joda-Time предлагает интерфейс MillisProvider и некоторые вспомогательные методы в DateTimeUtils . Таким образом, Joda-Time также может поддерживать тестовые модели с разными часами (издевательства и т.д.).

Арифметика продолжительности

Обе библиотеки поддерживают расчет временных расстояний в одной или нескольких временных единицах. Однако при обработке длительностей в одну единицу стиль JSR-310 явно лучше (и основывается на длинных, а не на использовании int):

JSR-310 => long days = ChronoUnit.DAYS.between(date1, date2);

Joda-Time => int days = DAYS.daysBetween(date1, date2).getDays();

Обработка множественных длительностей также различна. Даже результаты расчетов могут отличаться - см. Это закрыто выпуск Joda-Time . В то время как JSR-310 использует очень простой и ограниченный подход для использования только классов Period (длительность основана на годах, месяцах и днях) и Duration (основана на секундах и наносекундах), Joda-Time использует более сложный способ, используя класс PeriodType в Для того, чтобы контролировать, в каких единицах должна быть выражена продолжительность (Joda-Time называет ее "Период") Хотя PeriodType- API несколько неудобно для использования подобного способа, JSR-310 вообще не предлагается. В частности, в JSR-310 пока невозможно определить смешанную продолжительность даты и времени (например, на основе дней и часов). Так что будьте осторожны, если речь идет о миграции из одной библиотеки в другую. Обсуждаемые библиотеки несовместимы - несмотря на частично одинаковые имена классов.

Интервалы

JSR-310 не поддерживает эту функцию, в то время как Joda-Time имеет ограниченную поддержку. Смотрите также это SO-ответ .

Форматирование и анализ

Лучший способ сравнить обе библиотеки - это просмотреть классы с одинаковыми именами DateTimeFormatterBuilder (JSR-310) и DateTimeFormatterBuilder (Joda-Time). Вариант JSR-310 немного более мощный (он также может обрабатывать любые TemporalField при условии, что разработчику полей удалось закодировать некоторые точки расширения, такие как resol () ). Однако самое важное отличие - на мой взгляд:

JSR-310 может намного лучше анализировать имена часовых поясов (символ шаблона формата z), в то время как Joda-Time вообще не могла этого делать в своих более ранних версиях и теперь только очень ограниченным образом.

Еще одним преимуществом JSR-310 является поддержка автономных названий месяцев, что важно в таких языках, как русский или польский и т.д. Joda-Time имеет нет доступа к таким ресурсам - даже на платформах Java-8.

Синтаксис шаблона в JSR-310 также более гибок, чем в Joda-Time, допускает наличие необязательных секций (используя квадратные скобки), более ориентирован на стандарт CLDR и предлагает заполнение (буквенный символ p) и больше полей.

В противном случае следует отметить, что Joda-Time может форматировать длительности, используя PeriodFormatter . JSR-310 не может этого сделать.


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

Обновление от 2015-06-24:

Тем временем я нашел время написать и опубликовать табличный обзор для разных библиотек времени в Java. Таблицы также содержат сравнение между Joda-Time v2.8.1 и Java-8 (JSR-310). Это более подробно, чем этот пост.

391
Meno Hochschild

Java 8 Дата/Время:

  1. Классы Java 8 построены вокруг человеческого времени. Это делает их быстрыми для арифметики и преобразования даты и времени.
  2. Получатели компонента даты/времени, такие как getDayOfMonth, имеют O(1) сложность в Java 8 реализации.
  3. Синтаксический анализ OffsetDateTime/OffsetTime/ZonedDateTime очень медленный в Java 8 и b121 из-за исключительных ситуаций, возникающих и перехватываемых внутри JDK.
  4. Набор пакетов: Java.time.*, Java.time.chrono.*, Java.time.format.*, Java.time.temporal.*, Java.time.zone.*
  5. Экземпляры (временные метки) Дата и время Частичное Дата и время Парсер и форматер Часовые пояса Различные хронологии (календари).
  6. Существующие классы имеют проблемы, такие как Date не поддерживает I18N или L10N. Они изменчивы!
  7. Проще и надежнее.
  8. Часы могут быть введены.
  9. Часы могут быть созданы с различными свойствами - Статические часы, Смежные часы, Часы с низкой точностью (целые секунды, целые минуты и т.д.).
  10. Часы могут быть созданы с определенными часовыми поясами. Clock.system(Zone.of("America/Los_Angeles")).
  11. Делает тестирование даты и времени обработки кода.
  12. Делает тесты независимыми от часового пояса.

Joda-Time:

  1. Joda-Time использует машинное время внутри. Ручная реализация, основанная на значениях int/long, будет намного быстрее.
  2. Получатели Joda-Time требуют вычисления времени от компьютера к человеку для каждого вызова получателя, что делает Joda-Time узким местом в таких сценариях.
  3. Он состоит из неизменяемых классов, которые он обрабатывает Instants, Date & Time, Partials и Durations. Он гибкий. Он хорошо спроектирован.
  4. Представляет даты как моменты. Но дата и время могут соответствовать более чем одному мгновению. Час перекрытия, когда заканчивается летнее время. А также нет ни одного момента, который ему соответствует вообще. Разрыв в час, когда начинается дневной свет. Должен выполнять сложные вычисления для простых операций.
  5. Принимает пустые значения в качестве допустимых значений в большинстве своих методов. Приводит к тонким ошибкам.

Для более детального сравнения смотрите: -

производительность библиотеки Java 8 Date/Time (а также Joda-Time 2.3 и j.u.Calendar) . & Новый API даты и времени в Java 8

39
OO7