Я знаю, что есть вопросы, касающиеся java.util.Date и Joda-Time. Но после некоторого копания я не смог найти нить о различиях между java.time API (новый в Java 8, определяемый JSR 310) и Joda-Time.
Я слышал, что Java 8s java.time API намного чище и может делать гораздо больше, чем Joda-Time. Но я не могу найти примеры, сравнивающие их.
Общие функции
a) Обе библиотеки используют неизменяемые типы. Joda-Time также предлагает дополнительные изменяемые типы, такие как MutableDateTime.
b) Кроме того: обе библиотеки вдохновлены изучением дизайна "TimeAndMoney" от Эрика Эванса или идеи от Мартина Фаулера о доменном стиле, поэтому они более или менее стремятся к свободному стилю программирования (хотя и не всегда идеальны; -)).
c) В обеих библиотеках мы получаем реальный тип даты календаря (называемый LocalDate), тип реальной стены (называемый LocalTime) и состав (называемый LocalDateTime). Это очень большая победа по сравнению со старыми java.util.Calendar и java.util.Date.
d) Обе библиотеки используют метод-ориентированный подход, который означает, что пользователь рекомендует использовать getDayOfYear() вместо get(DAY_OF_YEAR). Это вызывает множество дополнительных методов по сравнению с java.util.Calendar (хотя последнее не является безопасным для всех из-за чрезмерного использования ints).
Производительность
См. другой ответ by @OO7, указывающий на анализ Михаила Воронцова, хотя точка 3 (исключение прилова), вероятно, устарела - см. эту JDK-ошибку. Различная производительность (что в целом благоприятствует JSR-310) объясняется главным образом тем, что внутренняя реализация Joda-Time всегда использует длительный примитив (в миллисекундах) в машинное время.
Null
Joda-Time часто использует NULL по умолчанию для системного часового пояса, стандартную локаль, текущую временную метку и т.д., в то время как JSR-310 почти всегда отклоняет значения NULL.
Точность
JSR-310 обрабатывает точность nanosecond, а Joda-Time ограничена точностью millisecond,
Поддерживаемые поля:
Обзор поддерживаемых полей в Java-8 (JSR-310) предоставляется некоторыми классами во временном пакете (например ChronoField и WeekFields), в то время как Joda-Time довольно слабо в этой области - см. DateTimeFieldType. Самым большим недостатком Joda-Time является отсутствие локализованных недельных полей. Общей чертой дизайна реализации на местах является то, что оба они основаны на значениях типа long (нет других типов, даже перечислений).
Enum
JSR-310 предлагает перечисления как DayOfWeek или Month, в то время как Joda-Time не предлагает этого, потому что он был разработан в основном в 2002-2004 годах до Java 5.
API зоны
a) JSR-310 предлагает больше возможностей часового пояса, чем Joda-Time. Latter не может предоставить программный доступ к истории переходов смещения временной зоны, в то время как JSR-310 способен это сделать.
b) Для вашей информации: JSR-310 переместил свой внутренний репозиторий часового пояса в новое место и другой формат. Старая папка библиотеки lib/zi больше не существует.
Настройщик против свойства
JSR-310 представила интерфейс TemporalAdjuster как формализованный способ экстернализации временных вычислений и манипуляций, особенно для библиотек или каркасных писателей. Это хороший и относительный простой способ встраивания новых расширений JSR-310 (a эквивалент статическим вспомогательным классам для прежних java.util.Date).
Однако для большинства пользователей эта функция имеет очень ограниченное значение, поскольку бремя для написания кода по-прежнему остается у пользователя. Встроенных решений, основанных на новом TemporalAdjuster -концепте, не так много, в настоящее время существует только вспомогательный класс TemporalAdjusters с ограниченным набором манипуляций (и перечислениями Month или другими временными типами).
Joda-Time предлагает полевой пакет, но практика показала, что новые реализации на местах очень сложно кодировать. С другой стороны, Joda-Time предлагает так называемые свойства, которые делают некоторые манипуляции намного проще и элегантнее, чем в JSR-310, например property.withMaximumValue().
Календарные системы
JSR-310 предлагает 4 дополнительных системы календаря. Наиболее интересным является Umalqura (используется в Саудовской Аравии). Остальные 3: Minguo (Тайвань), японский (только современный календарь с 1871 года!) И ThaiBuddhist (только после 1940 года).
Joda-Time предлагает исламский календарьоснованный на вычислительной базе - не календарный календарь, подобный Умалкуре. Тайд-буддист также предлагает Joda-Time в аналогичной форме, Minguo и японский. В противном случае Joda-Time также предлагает коптский и эфиопский календарь (но без поддержки интернационализации).
Более интересный для европейцев: Joda-Time также предлагает Gregorian, Julian и смешанный-gregorian-julian календарь. Однако практическая ценность реальных исторических вычислений ограничена, потому что важные функции, такие как начало года в истории даты, вообще не поддерживаются (одна и та же критика действительна для старых java.util.GregorianCalendar).
Другие календари, например Hebrew или персидский или Hindu полностью отсутствуют в обеих библиотеках.
Эпоха дней
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-answer.
Форматирование и анализ
Лучший способ сравнить обе библиотеки - просмотреть классы с равным именем DateTimeFormatterBuilder (JSR-310) и DateTimeFormatterBuilder (Joda-Time). Вариант JSR-310 немного более мощный (может также обрабатывать любой тип TemporalField, если разработчику поля удалось закодировать некоторые точки расширения, такие как resolve()). Однако самое важное различие - по-моему:
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). Это более подробно, чем этот пост.
Java 8 Дата/время:
getDayOfMonth, имеют сложность O (1) в реализации Java 8.OffsetDateTime/OffsetTime/ZonedDateTime очень медленный в Java 8 ea b121 из-за исключений, брошенных и пойманных внутри JDK.java.time.*, java.time.chrono.*, java.time.format.*, java.time.temporal.*, java.time.zone.*Clock.system(Zone.of("America/Los_Angeles")).Joda-Time:
Подробнее см.: -
Производительность библиотеки Java 8 Date/Time (а также Joda-Time 2.3 и j.u.Calendar). & Амп; Новый API дат и времени в Java 8