Общие черты
а) Обе библиотеки используют неизменяемые типы. Joda-Time также предлагает дополнительные изменяемые типы, такие как MutableDateTime
.
б) Более того: обе библиотеки вдохновлены исследованием дизайна «TimeAndMoney» Эрика Эванса или идеями Мартина Фаулера о доменно- ориентированном стиле, поэтому они более или менее стремятся к свободному стилю программирования (хотя не всегда идеально ;-)).
c) С обеими библиотеками мы получаем реальный тип календарной даты (называемый LocalDate
), реальный тип настенного времени (вызываемый LocalTime
) и композицию (вызываемый LocalDateTime
). Это очень большая победа по сравнению со старыми java.util.Calendar
и java.util.Date
.
г) Обе библиотеки используют метод, ориентированный на метод, то есть они поощряют использование пользователем getDayOfYear()
вместо get(DAY_OF_YEAR)
. Это вызывает много дополнительных методов по сравнению с java.util.Calendar
(хотя последний не является типобезопасным из-за чрезмерного использования целых).
Производительность
Посмотрите другой ответ @ OO7, указывающий на анализ Михаила Воронцова, хотя пункт 3 (отлов исключений), вероятно, устарел - см. Эту ошибку JDK . Различная производительность (что в целом в пользу JSR-310 ) в основном обусловлена тем фактом, что внутренняя реализация Joda-Time всегда использует подобный машинному времени длинный примитив (в миллисекундах).
Ноль
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
-concept, не так много, в настоящее время существует только вспомогательный класс TemporalAdjusters
с ограниченным набором манипуляций (и перечислений Month
или других временных типов).
Joda-Time предлагает пакет полей, но практика показала, что новые полевые реализации очень трудно кодировать. С другой стороны, Joda-Time предлагает так называемые свойства, которые делают некоторые манипуляции намного проще и элегантнее, чем в JSR-310, например, property.withMaximumValue () .
Календарные системы
JSR-310 предлагает 4 дополнительные календарные системы. Наиболее интересным является Umalqura (используется в Саудовской Аравии). Другие 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). Это более подробно, чем этот пост.