Différences entre L'API Date Time de Java 8 (java.temps) et Joda-temps

caractéristiques Communes

a) les deux bibliothèques utilisent des types immuables. Joda-Time propose également des types Mutants supplémentaires comme MutableDateTime .

B) de plus: les deux bibliothèques sont inspirées de l'étude de design "TimeAndMoney" d'Eric Evans ou des idées de Martin Fowler sur le style de domain driven de sorte qu'ils s'efforcent plus ou moins pour une fluent programming style (mais pas toujours parfait ;-)).

c) avec les deux bibliothèques, nous obtenons un type de date de calendrier réel (appelé LocalDate ), un type de temps de mur réel (appelé LocalTime ) et la composition (appelé LocalDateTime ). C'est une très grande victoire par rapport aux anciennes java.util.Calendar et java.util.Date .

d) Les deux bibliothèques utilisent une approche axée sur les méthodes, ce qui signifie qu'elles encouragent l'utilisateur à utiliser getDayOfYear() au lieu de get(DAY_OF_YEAR) . Cela provoque une beaucoup de méthodes supplémentaires par rapport à java.util.Calendar (bien que ce dernier n'est pas du tout sûr de type en raison de l'utilisation excessive de l'ints).

Performance

voir l'autre réponse de @OO7 pointant vers L'analyse de Mikhail Vorontsov bien que le point 3 (prise d'exception) est probablement obsolète - voir ce JDK-bug . La performance différente (qui est en général en faveur de JSR-310 ) est principalement en raison du fait que l'implémentation interne de Joda-Time utilise toujours une machine-time long-primitive (en millisecondes).

Null

Joda-Time utilise souvent NULL comme valeur par défaut pour le fuseau horaire du système, la locale par défaut, l'horodatage courant, etc. tandis que JSR-310 rejette presque toujours les valeurs nulles.

précision

JSR-310 traite la précision nanoseconde tandis que Joda-Time se limite à la précision milliseconde .

champs supportés:

un aperçu des champs supportés en Java-8 (JSR-310) est donné par certaines classes dans le paquet temporel (par exemple ChronoField et WeekFields ) alors que Joda-Time est plutôt faible sur ce domaine - voir DateTimeFieldType . Le plus grand manque de Joda-Time est ici l'absence de domaines localisés liés à la semaine. Une caractéristique commune à la conception de la mise en œuvre sur le terrain est que les deux sont basés sur des valeurs de type long (pas d'autres types, pas même enums).

Enum

JSR 310 offre enum comme DayOfWeek ou Month alors que Joda-Time n'est pas parce qu'il a été principalement développé dans les années 2002-2004 avant Java 5 .

Zone API

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 programmatique à l'histoire des transitions offset des fuseaux horaires 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 à un nouvel emplacement et un format différent. L'ancien dossier Bibliothèque lib / zi n'existe plus.

expert en sinistres vs. biens

JSR-310 a introduit la TemporalAdjuster - interface comme un moyen formalisé pour externaliser les calculs temporels et les manipulations, en particulier pour la bibliothèque ou les rédacteurs de cadre.c'est une façon agréable et relativement facile d'intégrer de nouvelles extensions de JSR-310 (une sorte d'équivalent des classes d'assistants statiques pour l'ancien java.util.Date ).

pour la plupart des utilisateurs, cependant, cette fonctionnalité a une valeur très limitée parce que la charge d'écrire le code est toujours avec 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 helper TemporalAdjusters avec un ensemble limité de manipulations (et les énums Month ou d'autres types temporels).

Joda-Time offre un paquet de champs mais la pratique a montré que les nouvelles implémentations de champs sont très difficiles à code. D'un autre côté, Joda-Time offre ce qu'on appelle des propriétés qui rendent certaines manipulations beaucoup plus faciles et plus élégantes que dans le JSR-310, par exemple la propriété .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: Mingo (Taiwan), Japonais (seulement le calendrier moderne depuis 1871!) et ThaiBuddhist (seul bon après 1940).

Joda-Time offre un calendrier islamique basé sur une base de calcul - pas un calendrier basé sur l'observation comme Umalqura. Thai-bouddhiste est également offert par Joda-Time dans une forme similaire, Mingo et le Japonais pas. Autrement Joda-Time offre le calendrier copte et Éthiopien, aussi (mais sans aucun soutien pour internationalisation.)

plus intéressant pour les Européens: Joda-Time offre également un grégorien , Julien et mixte-calendrier grégorien-Julien. Cependant, la valeur pratique pour les calculs historiques réels est limitée parce que les caractéristiques importantes comme les différentes dates de début d'année dans l'histoire de date ne sont pas soutenues du tout (la même critique est valide pour l'ancienne java.util.GregorianCalendar ).

autres calendriers comme hébreu ou persan ou Hindou sont complètement absentes dans les deux bibliothèques.

Epoch jours

JSR 310 a la classe JulianFields alors que Joda-Time (version 2.0) offre quelques méthodes d'aide 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 n'importe quelle injection de dépendance d'horloge. Joda-Time offre l'interface MillisProvider et quelques méthodes d'aide dans DateTimeUtils à la place. De cette façon, Joda-Time est également capable de supporter des modèles de tests avec différentes horloges (moqueries, etc.).).

durée arithmétique

les deux bibliothèques supportent le calcul des distances dans le temps dans une ou plusieurs unités temporelles. Cependant, lors de la manipulation de durées unitaires, le style JSR-310 est évidemment plus agréable (et plus long-basé au lieu d'utiliser int):

JSR-310 = > long days = ChronoUnit.DAYS.between(date1, date2);

Joda-Time = > int days = DAYS.daysBetween(date1, date2).getDays();

la manipulation de durées à unités multiples est également différente. Même les résultats de calcul peuvent différer - voir ce numéro fermait Joda-Time . 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 méthode plus sophistiquée en utilisant la classe PeriodType afin de contrôler dans quelles unités une durée (Joda-Time l'appelle "période") doit être exprimée. Alors que le PeriodType - API est en quelque sorte maladroit à utiliser une manière similaire n'est pas offert par JSR-310. En particulier, il n'est pas encore possible dans le JSR-310 de définir des dates et des durées mixtes (basées sur les jours et les heures par exemple). Soyez donc avertis s'il s'agit de migration d'une bibliothèque à une autre. Les bibliothèques en question sont incompatibles - malgré des noms de classe partiellement identiques.

intervalles

JSR-310 ne supporte pas cette fonctionnalité alors que Joda-Time a un support limité. Voir aussi ce SI réponse .

formatage et Parsing

la meilleure façon de comparer les deux bibliothèques est de voir les classes égales nommées DateTimeFormatterBuilder (JSR-310) et DateTimeFormatterBuilder (Joda-Time). La variante JSR-310 est un peu plus puissante (elle peut aussi gérer n'importe quel type de TemporalField à condition que l'exécuteur de champ ait réussi à coder une certaine extension des points comme resolve () ). Différence la plus importante est cependant, à mon avis:

JSR-310 peut beaucoup mieux analyser les noms de fuseaux horaires (format symbole de motif z) tandis que Joda-Time ne pouvait pas le faire du tout dans ses versions précédentes et maintenant seulement d'une 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 les langues comme le russe ou le polonais, etc. Joda-Time A Non accès à ces ressources -pas même sur les plates-formes Java-8.

la syntaxe du modèle dans JSR-310 est aussi plus flexible que dans Joda-Time, permet des sections optionnelles (en utilisant des crochets), est plus orientée vers CLDR-standard et offre un rembourrage (symbole lettre p) et plus de champs.

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

---

Espère que cet aperçu de l'aide. Toutes les informations recueillies est principalement là grâce à mes efforts et des enquêtes comment concevoir et mettre en œuvre une meilleure bibliothèque date-heure (rien n'est parfait).

mise à jour du 2015-06-24:

pendant ce temps j'ai trouvé le temps d'écrire et 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 post.