Ortak özellikler
a) Her iki kütüphane de değişmez tipler kullanır. Joda-Time ayrıca ek değişken tipleri de sunar MutableDateTime.
b) Ayrıca: Her iki kütüphaneden de Eric Evans'ın tasarım çalışması "TimeAndMoney" veya etki alanı güdümlü stil hakkında Martin Fowler'ın fikirlerinden esinlenerek akıcı bir programlama tarzı için az ya da çok çaba sarf ediyorlar (her zaman mükemmel olmasa da ;-)).
c) Her iki kütüphanede de gerçek bir takvim tarihi türü (denir LocalDate), gerçek bir duvar saati türü (denir LocalTime) ve kompozisyon (denir LocalDateTime) elde edilir. O eski ile karşılaştırıldığında çok büyük bir kazançtır java.util.Calendarve java.util.Date.
d) Her iki kütüphane de yöntemi merkezli bir yaklaşım kullanır, yani kullanıcıyı kullanmak getDayOfYear()yerine cesaretlendirir get(DAY_OF_YEAR). Bu, karşılaştırıldığında çok fazla ekstra yönteme neden olur java.util.Calendar(ikincisi aşırı miktarda kullanım nedeniyle hiç tür güvenli değildir).
Verim
@ OO7'nin Mikhail Vorontsov'un analizine işaret eden diğer cevabı görün, ancak nokta 3 (istisna yakalama) muhtemelen eski - bu JDK hatasını görün . Farklı performans (genel olarak JSR-310 lehine ) esas olarak Joda-Time'ın dahili uygulamasının her zaman makine zamanı benzeri uzun ilkel (milisaniye cinsinden) kullanmasından kaynaklanmaktadır.
Boş
Joda-Time genellikle sistem saat dilimi, varsayılan yerel ayar, geçerli zaman damgası vb. İçin varsayılan olarak NULL kullanır. JSR-310 neredeyse her zaman NULL değerlerini reddeder.
Hassas
Joda-Time milisaniye hassasiyetle sınırlıyken JSR-310 nanosaniye hassasiyetle çalışır.
Desteklenen alanlar:
Java-8'deki (JSR-310) desteklenen alanlar hakkında genel bilgi geçici paketteki bazı sınıflar tarafından verilir (örneğin ChronoField ve WeekFields ), Joda-Time bu alanda oldukça zayıftır - bkz. DateTimeFieldType . Joda-Time'ın en büyük eksikliği, burada yerelleştirilmiş haftala ilgili alanların olmamasıdır. Her iki saha uygulama tasarımının ortak bir özelliği, her ikisinin de uzun tip değerlere dayanmasıdır (başka türler, hatta numaralandırmalar değil).
Sıralama
JSR-310 teklifler enums gibi DayOfWeekveya MonthJoda-Time bunu sunmamaktadır ise çoğunlukla önce 2002-2004 yıllarında geliştirilen çünkü Java 5 .
Bölge API'sı
a) JSR-310, Joda-Time'dan daha fazla saat dilimi özelliği sunar. Sonuncusu, JSR-310 bunu yapabilirken, saat dilimi ofset geçişlerinin geçmişine programatik bir erişim sağlayamaz.
b) Bilginiz için: JSR-310 dahili saat dilimi deposunu yeni bir konuma ve farklı bir biçime taşımıştır. Eski kütüphane klasörü lib / zi artık mevcut değil.
Düzenleyici ve Mülkiyet
JSR-310 TemporalAdjuster, özellikle kütüphane veya çerçeve yazarları için zamansal hesaplamaları ve manipülasyonları dışsallaştırmak için resmi bir yol olarak -interface'i tanıttı. eski sınıflar java.util.Date).
Ancak çoğu kullanıcı için bu özellik çok sınırlı bir değere sahiptir, çünkü kod yazma yükü hala kullanıcıya aittir. New TemporalAdjuster-concept tabanlı yerleşik çözümler çok fazla değil, şu anda sadece TemporalAdjusterssınırlı bir manipülasyon seti olan yardımcı sınıf (ve numaralandırmalar Monthveya diğer geçici türler) var.
Joda-Time bir saha paketi sunuyor, ancak uygulama yeni saha uygulamalarının kodlanması çok zor olduğuna dair kanıtlar gösterdi. Diğer yandan Joda-Time, bazı manipülasyonları JSR-310'dan çok daha kolay ve zarif hale getiren özellikler sunar, örneğin property.withMaximumValue () .
Takvim sistemleri
JSR-310 4 ek takvim sistemi sunar. En ilginç olanı Umalqura'dır (Suudi Arabistan'da kullanılır). Diğer 3 tanesi: Minguo (Tayvan), Japonca (1871'den beri sadece modern takvim!) Ve ThaiBuddhist (sadece 1940'tan sonra düzeliyor ).
Joda-Time, Umalqura gibi nişangah tabanlı bir takvime değil, hesaplama tabanına dayalı İslami bir takvim sunuyor . Tay-Budist, Joda-Time tarafından Minguo ve Japonca değil benzer bir biçimde sunulmaktadır. Aksi takdirde Joda-Time da kıpti ve etiyopik takvim sunar (ancak uluslararasılaşma için herhangi bir destek olmadan).
Avrupalılar için daha ilginç: Joda-Time ayrıca bir Gregoryen , Julian ve karışık-gregoryan-julian takvimi sunuyor. Bununla birlikte, gerçek tarihsel hesaplamalar için pratik değer sınırlıdır, çünkü tarih tarihinde farklı yıl başlangıcı gibi önemli özellikler hiç desteklenmemektedir (aynı eleştiri eski için de geçerlidir java.util.GregorianCalendar).
İbranice veya Farsça veya Hindu gibi diğer takvimler her iki kütüphanede de eksiktir.
Dönem günleri
Joda-Time (sürüm 2.0) DateTimeUtils sınıfında bazı yardımcı yöntemler sunarken JSR-310 JulianFields sınıfına sahiptir .
saatler
JSR-310'da arabirim (tasarım hatası) yoktur ancak java.time.Clockherhangi bir saat bağımlılığı enjeksiyonu için kullanılabilen soyut bir sınıf vardır. Joda-Time, MillisProvider arabirimini ve DateTimeUtils'te bazı yardımcı yöntemler sunar . Böylece Joda-Time, farklı saatlere (alay etme vb.) Sahip test odaklı modelleri de destekleyebilir.
Süre aritmetiği
Her iki kütüphane de bir veya daha fazla zamansal birimde zaman mesafelerinin hesaplanmasını destekler. Ancak, tek birim sürelerle çalışırken JSR-310 stili açıkça daha güzeldir (ve int yerine uzun tabanlı):
JSR-310 => long days = ChronoUnit.DAYS.between(date1, date2);
Joda-Time => int days = DAYS.daysBetween(date1, date2).getDays();
Çok üniteli sürelerin kullanımı da farklıdır. Hesaplama sonuçları bile farklılık gösterebilir - bu kapalı Joda-Time sorununa bakın . JSR-310 sadece sınıfları Period(yıllar, aylar ve günler Durationbazında ) ve (saniye ve nanosaniye bazında ) kullanmak için çok basit ve sınırlı bir yaklaşım kullanırken, Joda-Time PeriodTypekontrol etmek için sınıfı kullanarak daha sofistike bir yöntem kullanır hangi birimlerde bir süre (Joda-Time "Dönem" olarak adlandırılır) ifade edilir. YaparkenPeriodType-API bir şekilde JSR-310 tarafından benzer bir şekilde kullanmak hiç de garip. Özellikle JSR-310'da karışık tarih ve saat sürelerini tanımlamak henüz mümkün değildir (örneğin gün ve saatlere göre). Bu yüzden bir kütüphaneden diğerine geçiş söz konusu olduğunda uyarınız. Tartışılan kütüphaneler, kısmen aynı sınıf adlarına rağmen uyumsuzdur.
Aralıklar
Joda-Time sınırlı bir desteğe sahipken JSR-310 bu özelliği desteklemez. Ayrıca bu SO-cevabına bakınız .
Biçimlendirme ve Ayrıştırma
Her iki kütüphaneyi karşılaştırmanın en iyi yolu, DateTimeFormatterBuilder (JSR-310) ve DateTimeFormatterBuilder (Joda-Time) adlı eşit sınıfları görüntülemektir . JSR-310 varyantı biraz daha güçlüdür ( TemporalFieldalan uygulayıcısının fix () gibi bazı uzantı noktalarını kodlamayı başarması şartıyla her türlü işlemi de yapabilir ). Ancak en önemli fark - bence:
JSR-310, saat dilimi adlarını (biçim deseni sembolü z) daha iyi ayrıştırabilirken, Joda-Time bunu önceki sürümlerinde hiç yapamadı ve şimdi sadece çok sınırlı bir şekilde.
JSR-310'un bir diğer avantajı, Rusça veya Lehçe vb. Dillerde önemli olan bağımsız ay adları için destek sağlamaktır. Joda-Time'ın Java-8 platformlarında bile bu kaynaklara erişimi yoktur .
JSR-310'daki desen sözdizimi Joda-Time'a göre daha esnektir, isteğe bağlı bölümlere (köşeli parantez kullanarak) izin verir, CLDR standardına göre daha yönlendirilir ve dolgu (harf sembolü p) ve daha fazla alan sunar.
Aksi takdirde Joda-Time'ın PeriodFormatter kullanarak süreleri biçimlendirebileceği unutulmamalıdır . JSR-310 bunu yapamaz.
Umarım bu genel bakış yardımcı olur. Toplanan tüm bilgiler, daha iyi bir tarih ve saat kütüphanesinin nasıl tasarlanacağı ve uygulanacağına dair çabalarım ve araştırmalarım nedeniyle oradadır (hiçbir şey mükemmel değildir).
2015-06-24'ten güncelleme:
Bu arada , Java'daki farklı zaman kitaplıkları için tablo halinde bir genel bakış yazma ve yayınlama zamanını buldum . Tablolar ayrıca Joda-Time v2.8.1 ve Java-8 (JSR-310) arasında bir karşılaştırma içerir. Bu yazıdan daha ayrıntılı.