web-dev-qa-db-fra.com

Différences entre Java 8 API Date Time (Java.time) et Joda-Time

Je sais qu'il y a des questions concernant Java.util.Date et Joda-Time. Mais après quelques recherches, je n'ai pas trouvé de fil concernant les différences entre Java.time API (nouveauté Java 8 , défini par JSR 31 ) et Joda-Time .

J’ai entendu dire que l’API Java.time de Java 8 est beaucoup plus propre et peut faire beaucoup plus que Joda-Time. Mais je ne trouve pas d'exemples comparant les deux.

  • Que peut faire Java.time que Joda-Time ne puisse pas?
  • Qu'est-ce que Java.time peut faire mieux que Joda-Time?
  • Les performances sont-elles meilleures avec Java.time?
javadatetimejava-8jodatimejava-time
252
Zack

Caractéristiques communes

a) Les deux bibliothèques utilisent des types immuables. Joda-Time propose également des types mutables supplémentaires tels que MutableDateTime.

b) En outre: les deux bibliothèques s’inspirent de l’étude de conception "TimeAndMoney" de Eric Evans ou des idées de Martin Fowler sur le style axé sur le domaine donc ils cherchent plus ou moins un style de programmation fluide (bien que pas toujours parfait ;-)).

c) Avec les deux bibliothèques, nous obtenons un type de date réelle (appelé LocalDate), un type de temps réel sur un mur (appelé LocalTime) et la composition (appelée LocalDateTime). C'est une très grosse victoire comparée aux anciennes Java.util.Calendar et Java.util.Date.

d) Les deux bibliothèques utilisent une approche centrée sur la méthode, c'est-à-dire qu'elles encouragent l'utilisateur à utiliser getDayOfYear() au lieu de get(DAY_OF_YEAR). Cela provoque beaucoup de méthodes supplémentaires par rapport à Java.util.Calendar (bien que ce dernier ne soit pas du tout sûr en termes de types en raison d'une utilisation excessive d'ints).

Performance

Voir l’autre réponse de @ OO7 pointant sur l’analyse de Mikhail Vorontsov bien que le point 3 (capture d’exception) soit probablement obsolète - voir ce bug JDK . La performance différente (qui est en faveur générale de JSR-310 ) est principalement due au fait que la mise en œuvre interne de Joda-Time utilisez toujours une primitive longue semblable à l'heure machine (en millisecondes).

Null

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 nanoseconde alors que Joda-Time est limité à la précision milliseconde .

Champs pris en charge:

Un aperçu des champs supportés dans Java-8 (JSR-310) est donné par certaines classes du paquet temporal (par exemple ChronoField et WeekFields ) alors que Joda-Time est plutôt faible sur cette zone - voir DateTimeFieldType . Le plus gros manque de Joda-Time est ici l'absence de champs localisés liés à la semaine. Une caractéristique commune à la conception d'implémentation sur le terrain 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 offre des enums comme DayOfWeek ou Month alors que Joda-Time ne l’offre 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. Ce dernier n'est pas en mesure de fournir un accès par programme à l'historique des transitions de décalage de fuseau horaire, alors que 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.

Adjuster vs. Property

JSR-310 a introduit l'interface TemporalAdjuster- en tant que moyen formalisé d'extérioriser les calculs et les manipulations temporelles, en particulier pour les rédacteurs de bibliothèque ou de framework. C'est un moyen simple et agréable d'intégrer de nouvelles extensions de JSR-310 (une sorte d'équivalent aux classes d'assistance statiques pour l'ancien Java.util.Date).

Toutefois, pour la plupart des utilisateurs, cette fonctionnalité a une valeur très limitée, car l’écriture du code incombe toujours à l’utilisateur. Les solutions intégrées basées sur le nouveau concept TemporalAdjuster- ne sont pas nombreuses, il n’existe actuellement que la classe d’aide TemporalAdjusters avec un ensemble limité de manipulations (et les enums Month ou d’autres méthodes temporelles). les types).

Joda-Time propose un ensemble de produits sur le terrain, mais la pratique montre que les nouvelles implémentations sur le terrain sont très difficiles à coder. De l'autre côté, Joda-Time offre des propriétés dites qui rendent certaines manipulations beaucoup plus simples et élégantes que dans JSR-310, par exemple property.withMaximumValue () .

Systèmes de calendrier

JSR-310 offre 4 systèmes de calendrier supplémentaires. Le plus intéressant est Umalqura (utilisé en Arabie Saoudite). Les 3 autres sont: Minguo (Taiwan), japonais (seul le calendrier moderne depuis 1871!) Et ThaiBuddhist (correct uniquement après 1940).

Joda-Time propose un calendrier islamique basé sur une base de calcul - et non un calendrier basé sur des observations comme Umalqura. Le bouddhiste thaïlandais est également proposé par Joda-Time sous une forme similaire, Minguo et le 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 mixte grégorien-julien. Cependant, la valeur pratique pour les calculs historiques réels est limitée car des fonctionnalités importantes, telles que des débuts différents dans l'historique des dates, ne sont pas prises en charge du tout (la même critique est valable pour l'ancien Java.util.GregorianCalendar).

D'autres calendriers tels que hébreu ou persan ou hindou sont complètement absents des deux bibliothèques. .

Epoch days

JSR-310 a la classe JulianFields alors 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.Clock qui peut être utilisée pour toute injection de dépendance d'horloge. Joda-Time offre l'interface MillisProvider et quelques méthodes d'assistance dans DateTimeUtils . Ainsi, Joda-Time est également capable de prendre en charge des modèles testés avec différentes horloges (moqueurs, etc.).

Durée arithmétique

Les deux bibliothèques prennent en charge le calcul des distances dans une ou plusieurs unités temporelles. Cependant, lors de la gestion de durées unitaires, le style JSR-310 est évidemment plus agréable (et basé longtemps 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 de plusieurs durées unitaires est également différente. Même les résultats des calculs peuvent différer - voyez cette question fermée de Joda-Time . Alors que JSR-310 utilise une approche très simple et limitée pour n’utiliser que les classes Period (durée en années, mois et jours) et Duration (en secondes et en nanosecondes), Joda-Time utilise manière plus sophistiquée en utilisant la classe PeriodType afin de contrôler en quelles unités une durée (Joda-Time l’appelle "période") doit être exprimée. Bien que la PeriodType- API soit difficile à utiliser de la même manière, JSR-310 ne propose pas du tout. En particulier, il n’est pas encore possible dans JSR-310 de définir des durées mixtes de date et d’heure (basées sur les jours et les heures, par exemple). Soyez donc averti s'il s'agit de la 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 fonctionnalité, alors que Joda-Time prend en charge une assistance limitée. Voir aussi ceci SO-answer .

Formatage et analyse

Le meilleur moyen de comparer les deux bibliothèques est d’afficher les classes portant le même nom DateTimeFormatterBuilder (JSR-310) et DateTimeFormatterBuilder (Joda-Time ). La variante JSR-310 est un peu plus puissante (elle peut également traiter tout type de TemporalField à condition que l’implémenteur de champs ait réussi à coder des points d’extension tels que resol () ). La différence la plus importante est cependant - à mon avis:

JSR-310 peut beaucoup mieux analyser les noms de fuseaux horaires (symbole de format z), tandis que Joda-Time ne pouvait pas le faire du tout dans ses versions précédentes et maintenant seulement de manière très limitée.

Un autre avantage de JSR-310 est la prise en charge de noms de mois autonomes, ce qui est important dans des langues telles que le russe ou le polonais, etc. Joda-Time n’a aucun accès à de telles ressources - pas même en Java- 8 plates-formes.

La syntaxe de motif dans JSR-310 est également plus souple que dans Joda-Time, permet des sections facultatives (à l'aide de crochets), est davantage orientée vers le standard CLDR et offre un remplissage (symbole de lettre p) et davantage de champs.

Sinon, il convient de noter que Joda-Time peut formater des durées en utilisant PeriodFormatter . JSR-310 ne peut pas faire cela.

J'espère que cette vue d'ensemble aide. Toutes les informations rassemblées sont principalement là en raison de mes efforts et de mes enquêtes sur la façon de concevoir et de mettre en œuvre une meilleure bibliothèque de date et heure (rien n’est parfait).

Mise à jour du 2015-06-24:

En attendant, j'ai trouvé le temps d'écrire et de publier un tableau récapitulatif 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). C'est plus détaillé que ce post.

398
Meno Hochschild

Java 8 Date/Heure:

  1. Les classes Java 8 sont construites autour du temps humain. Cela les rend rapides pour l’arithmétique/la conversion datetime humaine.
  2. Les getters de composant date/heure tels que getDayOfMonth ont la complexité O(1) dans _ la mise en œuvre Java 8.
  3. L'analyse de OffsetDateTime/OffsetTime/ZonedDateTime est très lente dans Java 8 ea b121 en raison d'exceptions renvoyées et interceptées en interne dans le JDK.
  4. Un ensemble de paquets: Java.time.*, Java.time.chrono.*, Java.time.format.*, Java.time.temporal.*, Java.time.zone.*
  5. Instants (horodatages) Date et heure Partielle Date et heure Fuseaux horaires de l'analyseur et du formateur Différentes chronologies (calendriers).
  6. Les classes existantes ont des problèmes comme Date ne prend pas en charge I18N ou L10N. Ils sont mutables!
  7. Plus simple et plus robuste.
  8. Les horloges peuvent être injectées.
  9. Des horloges peuvent être créées avec différentes propriétés - horloges statiques, horloges simulées, horloges de faible précision (secondes entières, minutes entières, etc.).
  10. Des horloges peuvent être créées avec des fuseaux horaires spécifiques. Clock.system(Zone.of("America/Los_Angeles")).
  11. Permet de tester la date et l'heure de traitement du code.
  12. Rend les tests indépendants du fuseau horaire.

Joda-Time:

  1. Joda-Time utilise le temps machine à l'intérieur. Une implémentation manuelle basée sur des valeurs int/long serait beaucoup plus rapide.
  2. Les getters de Joda-Time requièrent un calcul du temps ordinateur à humain à chaque appel de getter, ce qui fait de Joda-Time un goulot d'étranglement dans de tels scénarios.
  3. Composé de classes immuables, il gère les instants, la date et l’heure, les partiels et les durées. Il est flexible. Il est bien conçu.
  4. Représente les dates sous forme d'instants. Mais une date et une heure peuvent correspondre à plus d’un instant. Heure de chevauchement lorsque l'heure avancée se termine. En plus de ne pas avoir d'instant qui lui correspond du tout. Heure de décalage lorsque le jour commence. Doit effectuer des calculs complexes pour des opérations simples.
  5. Accepte les valeurs NULL comme valeurs valides pour la plupart de ses méthodes. Conduit à des bugs subtils.

Pour une comparaison plus détaillée, voir: -

Performance de la bibliothèque Java 8 Date/Time (ainsi que Joda-Time 2.3 et j.u.Calendar) . & Nouvelle API de date et heure dans Java 8

41
OO7