Wspólne cechy
a) Obie biblioteki używają niezmiennych typów. Joda-Time oferuje również dodatkowe typy zmienne, takie jak MutableDateTime.
b) Ponadto: Obie biblioteki zostały zainspirowane studiami projektowymi „TimeAndMoney” Erica Evansa lub pomysłami Martina Fowlera na temat stylu opartego na domenie, więc starają się mniej więcej o płynny styl programowania (choć nie zawsze idealny ;-)).
c) W obu bibliotekach otrzymujemy prawdziwy typ daty kalendarza (nazywany LocalDate), prawdziwy typ czasu na ścianie (nazywany LocalTime) i kompozycję (nazywany LocalDateTime). To bardzo duża wygrana w porównaniu ze starymi java.util.Calendari java.util.Date.
d) Obie biblioteki stosują podejście zorientowane na metody, co oznacza, że zachęcają użytkownika do korzystania getDayOfYear()zamiast get(DAY_OF_YEAR). Powoduje to wiele dodatkowych metod w porównaniu z java.util.Calendar(chociaż ta ostatnia nie jest w ogóle bezpieczna dla typu z powodu nadmiernego użycia int).
Występ
Zobacz inną odpowiedź @ OO7 wskazującą na analizę Michaiła Woroncowa, chociaż punkt 3 (wyłapywanie wyjątków) jest prawdopodobnie przestarzały - zobacz ten błąd JDK . Różna wydajność (która jest ogólnie na korzyść JSR-310 ) wynika głównie z faktu, że wewnętrzna implementacja Joda-Time zawsze używa czasu pierwotnego podobnego do czasu maszynowego (w milisekundach).
Zero
Joda-Time często używa NULL jako domyślnej strefy czasowej systemu, domyślnych ustawień regionalnych, bieżącego znacznika czasu itp., Podczas gdy JSR-310 prawie zawsze odrzuca wartości NULL.
Precyzja
JSR-310 obsługuje precyzję nanosekundową, a czas Joda jest ograniczony do precyzji milisekundowej .
Obsługiwane pola:
Przegląd obsługiwanych pól w Javie-8 (JSR-310) jest podawany przez niektóre klasy w pakiecie czasowym (na przykład ChronoField i WeekFields ), podczas gdy Joda-Time jest raczej słaby w tym obszarze - patrz DateTimeFieldType . Największym brakiem Joda-Time jest tutaj brak zlokalizowanych pól związanych z tygodniem. Wspólną cechą obydwu projektów implementacji w terenie jest to, że oba oparte są na wartościach typu long (żadnych innych typów, nawet wyliczeń).
Enum
JSR-310 oferuje wyliczenia takie jak DayOfWeeklub Monthpodczas gdy Joda-Time nie oferuje tego, ponieważ został opracowany głównie w latach 2002-2004 przed Javą 5 .
Strefa API
a) JSR-310 oferuje więcej funkcji strefy czasowej niż Joda-Time. Później nie jest w stanie zapewnić programowego dostępu do historii przejść przesunięcia strefy czasowej, podczas gdy JSR-310 jest w stanie to zrobić.
b) Dla twojej informacji: JSR-310 przeniósł swoje wewnętrzne repozytorium strefy czasowej do nowej lokalizacji i innego formatu. Stary folder biblioteki lib / zi już nie istnieje.
Dostrajacz a własność
JSR-310 wprowadził TemporalAdjusterinterfejs jako sformalizowany sposób uzewnętrznienia obliczeń i manipulacji czasowych, szczególnie dla bibliotek lub twórców frameworków. Jest to miły i względnie łatwy sposób na osadzenie nowych rozszerzeń JSR-310 (rodzaj odpowiednika statycznego pomocnika zajęcia dla byłych java.util.Date).
Jednak dla większości użytkowników ta funkcja ma bardzo ograniczoną wartość, ponieważ ciężar pisania kodu nadal spoczywa na użytkowniku. Wbudowanych rozwiązań opartych na nowej TemporalAdjusterkoncepcji nie jest tak wiele, obecnie istnieje tylko klasa pomocnicza TemporalAdjustersz ograniczonym zestawem manipulacji (oraz wyliczeniami Monthlub innymi typami czasowymi).
Joda-Time oferuje pakiet terenowy, ale praktyka wykazała, że nowe implementacje w terenie są bardzo trudne do kodowania. Z drugiej strony Joda-Time oferuje tak zwane właściwości, które sprawiają, że niektóre manipulacje są znacznie łatwiejsze i bardziej eleganckie niż w JSR-310, na przykład property.withMaximumValue () .
Systemy kalendarza
JSR-310 oferuje 4 dodatkowe systemy kalendarza. Najciekawszym jest Umalqura (używany w Arabii Saudyjskiej). Pozostałe 3 to: Minguo (Tajwan), japoński (tylko współczesny kalendarz od 1871 r.!) I ThaiBuddhist (tylko poprawny po 1940 r.).
Joda-Time oferuje islamski kalendarz oparty na podstawie obliczeniowej - a nie kalendarz oparty na obserwacji, taki jak Umalqura. Tajski-buddyjski jest również oferowany przez Joda-Time w podobnej formie, Minguo i japoński nie. W przeciwnym razie Joda-Time oferuje także kalendarz koptyjski i etiopski (ale bez wsparcia dla internacjonalizacji).
Bardziej interesujące dla Europejczyków: Joda-Time oferuje również kalendarz gregoriański , juliański i mieszany gregoriańsko-julijski. Jednak praktyczna wartość rzeczywistych obliczeń historycznych jest ograniczona, ponieważ ważne funkcje, takie jak historia różnych dat rozpoczęcia roku, nie są w ogóle obsługiwane (ta sama krytyka obowiązuje dla starych java.util.GregorianCalendar).
Inne kalendarze jak hebrajskim lub perski lub Hindu są całkowicie brakuje w obu bibliotekach.
Dni epoki
JSR-310 ma klasę JulianFields, a Joda-Time (wersja 2.0) oferuje pewne metody pomocnicze w klasie DateTimeUtils .
Zegary
JSR-310 nie ma interfejsu (błąd projektowy), ale abstrakcyjną klasę, java.time.Clockktórej można użyć do dowolnego wstrzykiwania zależności zegara. Joda-Time oferuje zamiast tego interfejs MillisProvider i niektóre metody pomocnicze w DateTimeUtils . W ten sposób Joda-Time może również obsługiwać modele testowane z różnymi zegarami (kpiny itp.).
Czas trwania arytmetyki
Obie biblioteki obsługują obliczanie odległości czasowych w co najmniej jednej jednostce czasowej. Jednak podczas obsługi czasów trwania pojedynczych jednostek styl JSR-310 jest oczywiście ładniejszy (i oparty na długim zakresie zamiast używania int):
JSR-310 => long days = ChronoUnit.DAYS.between(date1, date2);
Czas Joda => int days = DAYS.daysBetween(date1, date2).getDays();
Różne są także czasy trwania wielu jednostek. Nawet wyniki obliczeń mogą się różnić - zobacz ten zamknięty problem Joda-Time . Podczas gdy JSR-310 stosuje bardzo proste i ograniczone podejście do korzystania tylko z klas Period(czas trwania oparty na latach, miesiącach i dniach) i Duration(oparty na sekundach i nanosekundach), Joda-Time używa bardziej wyrafinowanego sposobu korzystania z klasy PeriodTypew celu kontroli w których jednostkach należy wyrazić czas trwania (nazywany Joda „okresem”). Podczas, gdyPeriodType-API jest w jakiś sposób niewygodny w użyciu w podobny sposób, że JSR-310 w ogóle go nie oferuje. Szczególnie w JSR-310 nie jest jeszcze możliwe zdefiniowanie mieszanych czasów i dat (np. Na podstawie dni i godzin). Ostrzegaj więc, jeśli chodzi o migrację z jednej biblioteki do drugiej. Omawiane biblioteki są niekompatybilne - pomimo częściowo takich samych nazw klas.
Interwały
JSR-310 nie obsługuje tej funkcji, a Joda-Time ma ograniczone wsparcie. Zobacz także tę odpowiedź SO .
Formatowanie i parsowanie
Najlepszym sposobem na porównanie obu bibliotek jest wyświetlenie klas o takich samych nazwach DateTimeFormatterBuilder (JSR-310) i DateTimeFormatterBuilder (Joda-Time). Wariant JSR-310 jest nieco bardziej wydajny (może również obsługiwać dowolny rodzaj, pod TemporalFieldwarunkiem że implementatorowi pola udało się zakodować niektóre punkty rozszerzenia, takie jak resol () ). Najważniejsza różnica jest jednak - moim zdaniem:
JSR-310 może znacznie lepiej analizować nazwy stref czasowych (symbol wzorca formatu z), podczas gdy Joda-Time nie mógł tego zrobić w swoich wcześniejszych wersjach i teraz tylko w bardzo ograniczony sposób.
Kolejną zaletą JSR-310 jest obsługa samodzielnych nazw miesięcy, co jest ważne w językach takich jak rosyjski lub polski itp. Joda-Time nie ma dostępu do takich zasobów - nawet na platformach Java-8.
Składnia wzoru w JSR-310 jest również bardziej elastyczna niż w Joda-Time, pozwala na opcjonalne sekcje (za pomocą nawiasów kwadratowych), jest bardziej zorientowana na standard CLDR i oferuje wypełnianie (symbol litery p) i więcej pól.
W przeciwnym razie należy zauważyć, że Joda-Time może formatować czasy trwania za pomocą PeriodFormatter . JSR-310 nie może tego zrobić.
Mam nadzieję, że ten przegląd pomaga. Wszystkie zebrane informacje są tam głównie dzięki moim wysiłkom i badaniom, jak zaprojektować i wdrożyć lepszą bibliotekę daty i godziny (nic nie jest idealne).
Aktualizacja z dnia 24.06.2015:
Tymczasem znalazłem czas na napisanie i opublikowanie tabelarycznego przeglądu różnych bibliotek czasu w Javie. Tabele zawierają również porównanie między Joda-Time v2.8.1 i Java-8 (JSR-310). Jest bardziej szczegółowy niż ten post.