Caractéristiques communes
a) Les deux bibliothèques utilisent des types immuables. Joda-Time propose également des types mutables supplémentaires comme MutableDateTime.
b) En outre: Les deux bibliothèques sont inspirées par l'étude de conception "TimeAndMoney" d'Eric Evans ou les idées de Martin Fowler sur le style piloté par domaine afin qu'elles s'efforcent plus ou moins pour un style de programmation fluide (bien que pas toujours parfait ;-)).
c) Avec les deux bibliothèques, nous obtenons un type de date de calendrier réel (appelé LocalDate), un type d'heure de mur réel (appelé LocalTime) et la composition (appelée LocalDateTime). C'est une très grosse victoire par rapport aux anciens java.util.Calendaret aux java.util.Date.
d) Les deux bibliothèques utilisent une approche centrée sur la méthode, ce qui signifie qu'elles encouragent l'utilisateur à utiliser à la getDayOfYear()place de get(DAY_OF_YEAR). Cela entraîne beaucoup de méthodes supplémentaires par rapport à java.util.Calendar(bien que cette dernière ne soit pas du tout sûre pour le type en raison d'une utilisation excessive des pouces).
Performance
Voir l'autre réponse de @ OO7 pointant vers l'analyse de Mikhail Vorontsov bien que le point 3 (capture d'exception) soit probablement obsolète - voir ce bug JDK . Les performances différentes (qui sont en général en faveur de JSR-310 ) sont principalement dues au fait que l'implémentation interne de Joda-Time utilise toujours une primitive longue de type machine (en millisecondes).
Nul
Joda-Time utilise souvent NULL par défaut pour le fuseau horaire du système, les paramètres régionaux par défaut, l'horodatage actuel, etc. tandis que JSR-310 rejette presque toujours les valeurs NULL.
Précision
JSR-310 gère la précision en nanosecondes tandis que Joda-Time est limité à la précision en millisecondes .
Champs pris en charge:
Un aperçu des champs pris en charge dans Java-8 (JSR-310) est donné par certaines classes du package temporel (par exemple ChronoField et WeekFields ) tandis que Joda-Time est plutôt faible dans ce domaine - voir DateTimeFieldType . Le plus grand manque de Joda-Time est ici l'absence de champs localisés liés à la semaine. Une caractéristique commune de la conception d'implémentation des deux champs est que les deux sont basés sur des valeurs de type long (pas d'autres types, pas même des énumérations).
Enum
JSR-310 propose des énumérations comme DayOfWeekou Monthalors que Joda-Time ne le propose pas car il a été principalement développé dans les années 2002-2004 avant Java 5 .
API de zone
a) JSR-310 offre plus de fonctionnalités de fuseau horaire que Joda-Time. Latter n'est pas en mesure de fournir un accès par programmation à l'historique des transitions de décalage de fuseau horaire tandis que le JSR-310 est capable de le faire.
b) Pour votre information: JSR-310 a déplacé son référentiel de fuseau horaire interne vers un nouvel emplacement et un format différent. L'ancien dossier de bibliothèque lib / zi n'existe plus.
Ajusteur vs propriété
JSR-310 a introduit TemporalAdjuster-l'interface comme un moyen formalisé d'externaliser les calculs et les manipulations temporelles, en particulier pour les rédacteurs de bibliothèques ou de frameworks. cours pour anciens java.util.Date).
Cependant, pour la plupart des utilisateurs, cette fonctionnalité a une valeur très limitée car la charge d'écrire du code incombe toujours à l'utilisateur. Les solutions intégrées basées sur le nouveau TemporalAdjuster-concept ne sont pas si nombreuses, il n'y a actuellement que la classe d'assistance TemporalAdjustersavec un ensemble limité de manipulations (et les énumérations Monthou autres types temporels).
Joda-Time propose un package de terrain, mais la pratique a montré que les nouvelles implémentations de terrain sont très difficiles à coder. D'un autre côté, Joda-Time propose des soi-disant propriétés qui rendent certaines manipulations beaucoup plus faciles et plus élégantes que dans JSR-310, par exemple property.withMaximumValue () .
Systèmes de calendrier
JSR-310 propose 4 systèmes de calendrier supplémentaires. Le plus intéressant est Umalqura (utilisé en Arabie Saoudite). Les 3 autres sont: Minguo (Taiwan), japonais (seulement le calendrier moderne depuis 1871!) Et ThaiBuddhist (seulement correct après 1940).
Joda-Time propose un calendrier islamique basé sur une base de calcul - pas un calendrier basé sur l'observation comme Umalqura. Thai-Buddhist est également proposé par Joda-Time sous une forme similaire, Minguo et japonais non. Sinon, Joda-Time propose également un calendrier copte et éthiopique (mais sans aucun support pour l'internationalisation).
Plus intéressant pour les Européens: Joda-Time propose également un calendrier grégorien , julien et grégorien-julien mixte. Cependant, la valeur pratique pour les calculs historiques réels est limitée car des caractéristiques importantes telles que les différentes années de début dans l'historique des dates ne sont pas du tout prises en charge (la même critique est valable pour les anciens java.util.GregorianCalendar).
D'autres calendriers comme l' hébreu ou le persan ou l' hindou manquent complètement dans les deux bibliothèques.
Jours d'époque
JSR-310 a la classe JulianFields tandis que Joda-Time (version 2.0) propose des méthodes d'assistance dans la classe DateTimeUtils .
Horloges
JSR-310 n'a pas d'interface (une erreur de conception) mais une classe abstraite java.time.Clockqui peut être utilisée pour toute injection de dépendance d'horloge. Joda-Time propose à la place l'interface MillisProvider et certaines méthodes d'assistance dans DateTimeUtils . Ainsi, Joda-Time est également capable de prendre en charge des modèles pilotés par les tests avec différentes horloges (moqueries, etc.).
Durée arithmétique
Les deux bibliothèques prennent en charge le calcul des distances temporelles dans une ou plusieurs unités temporelles. Cependant, lors de la gestion de durées d'une seule unité, le style JSR-310 est évidemment plus agréable (et basé sur une longue au lieu d'utiliser int):
JSR-310 => long days = ChronoUnit.DAYS.between(date1, date2);
Joda-Time => int days = DAYS.daysBetween(date1, date2).getDays();
La gestion des durées à unités multiples est également différente. Même les résultats des calculs peuvent différer - voir ce problème Joda-Time fermé . Alors que JSR-310 utilise une approche très simple et limitée pour utiliser uniquement les classes Period(durée basée sur les années, les mois et les jours) et Duration(basée sur les secondes et les nanosecondes), Joda-Time utilise une manière plus sophistiquée en utilisant la classe PeriodTypeafin de contrôler dans quelles unités une durée (Joda-Time l'appelle "Période") doit être exprimée. Tandis que lePeriodType-API est en quelque sorte difficile à utiliser d'une manière similaire n'est pas du tout proposé par JSR-310. Surtout, il n'est pas encore possible dans JSR-310 de définir des durées de date et d'heure mixtes (basées sur les jours et les heures par exemple). Soyez donc prévenu en cas de migration d'une bibliothèque à une autre. Les bibliothèques en discussion sont incompatibles - malgré des noms de classe partiellement identiques.
Intervalles
JSR-310 ne prend pas en charge cette fonction tandis que Joda-Time a un support limité. Voir aussi cette réponse SO .
Formatage et analyse
La meilleure façon de comparer les deux bibliothèques consiste à afficher les classes de nom égal DateTimeFormatterBuilder (JSR-310) et DateTimeFormatterBuilder (Joda-Time). La variante JSR-310 est un peu plus puissante (peut également gérer n'importe quel type à TemporalFieldcondition que l'implémentateur de champ ait réussi à coder certains points d'extension comme resolver () ). La différence la plus importante est cependant - à mon avis:
JSR-310 peut mieux analyser les noms de fuseau horaire (symbole de modèle de format z) tandis que Joda-Time ne pouvait pas du tout le faire dans ses versions antérieures et maintenant seulement de manière très limitée.
Un autre avantage de JSR-310 est la prise en charge des noms de mois autonomes, ce qui est important dans des langues comme le russe ou le polonais, etc. Joda-Time n'a pas accès à ces ressources - pas même sur les plates-formes Java-8.
La syntaxe de modèle dans JSR-310 est également plus flexible que dans Joda-Time, permet des sections optionnelles (en utilisant des crochets), est plus orientée vers la norme CLDR et offre un remplissage (symbole de lettre p) et plus de champs.
Sinon, il convient de noter que Joda-Time peut formater les durées à l'aide de PeriodFormatter . JSR-310 ne peut pas faire cela.
J'espère que cet aperçu vous aidera. Toutes les informations recueillies sont principalement là grâce à mes efforts et à mes recherches pour concevoir et implémenter une meilleure bibliothèque de date et d'heure (rien n'est parfait).
Mise à jour du 24/06/2015:
En attendant, j'ai trouvé le temps d'écrire et de publier un aperçu tabulaire pour différentes bibliothèques de temps en Java. Les tableaux contiennent également une comparaison entre Joda-Time v2.8.1 et Java-8 (JSR-310). Il est plus détaillé que ce billet.