Загальні риси
а) Обидві бібліотеки використовують незмінні типи. Joda-Time також пропонує додаткові типи змінних, наприклад MutableDateTime.
b) Крім того: обидві бібліотеки натхненні дизайнерським дослідженням "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 (жодних інших типів, навіть не перерахунків).
Енум
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 (свого роду еквівалент статичному помічнику) заняття для колишніх java.util.Date).
Однак для більшості користувачів ця функція має дуже обмежене значення, оскільки навантаження на код залишається за користувачем. Вбудованих рішень, заснованих на новій TemporalAdjuster-концепції, не так вже й багато, в даний час існує лише хелперний клас TemporalAdjustersз обмеженим набором маніпуляцій (і переліків, Monthабо інших часових типів).
Joda-Time пропонує польовий пакет, але практика показала, що нові польові реалізації дуже важко кодувати. З іншого боку, Joda-Time пропонує так звані властивості, які роблять деякі маніпуляції набагато простішими та елегантнішими, ніж у JSR-310, наприклад, property.withMaximumValue () .
Календарні системи
JSR-310 пропонує 4 додаткові календарні системи. Найцікавіший - Умальква (використовується в Саудівській Аравії). Інші 3: Minguo (Тайвань), японський (лише сучасний календар з 1871 року!) Та ThaiBuddhist (правильний лише після 1940 року).
Joda-Time пропонує ісламський календар на основі калькуляційної бази, а не календаря, який базується на прицілі, як Умальква. Тайський-буддистський також пропонує 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 має обмежену підтримку. Дивіться також цю відповідь .
Форматування та розбір
Найкращим способом порівняння обох бібліотек є перегляд рівних названих класів DateTimeFormatterBuilder (JSR-310) та DateTimeFormatterBuilder (Joda-Time). Варіант JSR-310 є трохи більш потужним (може також обробляти будь-які види, TemporalFieldякщо польовий реалізатор зумів зашифрувати деякі точки розширення, такі як резоль () ). Однак найголовніша різниця - на мою думку:
JSR-310 може набагато краще проаналізувати назви часових поясів (символ формату z), тоді як Joda-Time не може цього зробити взагалі в своїх попередніх версіях і тепер лише дуже обмеженим чином.
Ще одна перевага JSR-310 - підтримка автономних імен місяців, що важливо на таких мовах, як російська чи польська тощо. Joda-Time не має доступу до таких ресурсів - навіть на платформах Java-8.
Синтаксис шаблону в JSR-310 також є більш гнучким, ніж у Joda-Time, дозволяє отримати необов'язкові розділи (використовуючи квадратні дужки), більш орієнтований на стандарт CLDR і пропонує прошивку (символ букви p) та більше полів.
В іншому випадку слід зазначити, що Joda-Time може форматувати тривалість за допомогою PeriodFormatter . JSR-310 цього не може зробити.
Сподіваюся, цей огляд допомагає. Уся зібрана інформація є, головним чином, завдяки моїм зусиллям та розслідуванням, як створити та впровадити кращу бібліотеку з датами та часом (нічого не ідеального).
Оновлення від 24.06.2015:
Тим часом я знайшов час писати та публікувати табличний огляд для різних бібліотек часу на Java. Таблиці містять також порівняння між Joda-Time v2.8.1 та Java-8 (JSR-310). Вона детальніше, ніж ця публікація.