Bien que Joda soit riche en fonctionnalités et plus sophistiqué que le temps Java standard, ce n'est pas toujours la meilleure chose à utiliser. Comment puis-je décider si je dois utiliser Joda Time ou Java Time dans un code Java?

Existe-t-il une sorte de directive qui nous indique comment choisir la bonne en fonction de nos besoins?

Joda Time est une telle amélioration par rapport à la bibliothèque de temps Java qu'il est presque toujours le bon choix, à l'exception des exceptions suivantes:

1. Lorsqu'il est difficile ou indésirable d'ajouter des dépendances tierces à votre projet

2. Lorsque son utilisation dans une interface publique entraînerait des problèmes, par exemple obtenir un ORM pour gérer à la fois les champs de temps java et Joda

Cependant, dans le cas de 2), il serait toujours préférable d'utiliser Joda en interne si possible.

Les choses ci-dessus méritent d'être gardées à l'esprit, mais devraient être rares. En cas de doute, rendez-vous avec Joda.

Notez que sur le site Web de Joda-Time, il est indiqué:

Les classes de date et d'heure standard avant Java SE 8 sont médiocres. En s'attaquant de front à ce problème, Joda-Time est devenu la bibliothèque standard de facto de date et d'heure pour Java. Notez qu'à partir de Java SE 8, les utilisateurs sont invités à migrer vers java.time (JSR-310).

Le principal contributeur de Joda-Time , jodastephen , est également le principal contributeur de JSR-310, comme on peut le voir sur le référentiel GitHub associé à http://www.threeten.org/ . Soit dit en passant, jodastephen a également une poignée SO ...

Je pense qu'il est sûr d'affirmer que nous pouvons nous sentir à l'aise et en sécurité avec la nouvelle API de date et d'heure fournie par Java 8 .

Quelques références supplémentaires:

• Page Web officielle du JCP-310
• Joda-Time
• Trois dix
• java.time.* Javadoc
• Date Javadoc

L'API de date standard Java est si fondamentalement cassée que j'ai souvent envisagé d'ajouter simplement Joda Time aux extensions de bibliothèque de la JVM pour qu'elle se charge par défaut sur le chemin de classe avec le reste de l'API Java.

Si vous avez déjà été chargé de moderniser l'internationalisation et les fuseaux horaires dans une application Java héritée et que vous avez essayé d'utiliser l'API Java standard seul, vous comprendrez ce que je veux dire. J'ai pu transformer des milliers de lignes de code asinine en moins d'une centaine. L'augmentation de la productivité est inconcevable.

De plus, l'API Date standard n'est pas intuitive, où l'API Joda fluide peut être récupérée en heures et non en semaines. Votre analogie d'essayer d'arriver à l'île qui est à deux miles de distance, est plus semblable à ce qui suit.

1) Un bateau à moteur qui vous amènera sur l'île en seulement 6 minutes.

Ou...

2) Un radeau de bambou de fortune attaché avec des vignes lors d'un ouragan dirigé par un fou dont le meilleur ami est un volley-ball.

Comme d'autres réponses l'ont indiqué, les quelques inconvénients tels que l'ORM deviennent même inexistants car Hibernate a maintenant des plugins qui permettent aux propriétés de bean de type Joda d'être mappées aux champs de date / heure de la base de données. JPA pourrait également avoir une réponse à cela.

Si vous souhaitez que votre application ait une empreinte minimaliste en tant qu'application de bureau en ce qui concerne l'espace disque, Java n'est peut-être même pas le bon choix de langue.

Un autre point: Java-Time (ie Date) n'est pas ThreadSafe mais JodaTime l'est. JodaTime est donc préférable lorsque des exigences telles que

• Environnement multithread accédant aux ressources communes
• Synchronisation temporelle centralisée comme les situations

Ou bien pour les applications simples, Java-Time est correct.

Le framework java.time remplace à la fois les classes date-heure héritées et Joda-Time

Mise à jour: les anciennes classes de date et d'heure livrées avec les premières versions de Java sont désormais héritées, officiellement supplantées par les classes java.time intégrées à Java 8, Java 9 et versions ultérieures.

Date, Calendar, SimpleDateFormat, Et les java.sql.*cours de date-heure devraient tous être évités. Il n'est jamais nécessaire d'utiliser ces classes déroutantes, gênantes et mal conçues. Ils sont entièrement remplacés par des classes java.time. Leur seul but est maintenant de maintenir l'ancien code existant. Lors de l'interface avec l'ancien code, vous pouvez convertir vers / depuis java.time en appelant de nouvelles méthodes ajoutées aux anciennes classes. Pour plus d'informations sur la conversion, voir: Convertir java.util.Date en quel type "java.time"? .

Le projet Joda-Time , désormais en mode maintenance , conseille la migration vers les classes java.time . Le projet Joda-Time a inspiré le framework java.time. Les deux sont dirigés par le même homme, Stephen Colebourne . Vous pouvez considérer java.time comme une réécriture / refonte de Joda-Time, tout nouveau code, mais utilisant ce qui a été appris au fil des ans depuis la construction de la première bibliothèque de date-heure complète et sophistiquée de l'industrie.

Pour en savoir plus, consultez le didacticiel Oracle . Et recherchez Stack Overflow pour de nombreux exemples et explications.

Une grande partie de la fonctionnalité java.time est rétroportée vers Java 6 et 7 dans ThreeTen-Backport et adaptée à Android dans ThreeTenABP (voir Comment utiliser… ).

Le projet ThreeTen-Extra étend java.time avec des classes supplémentaires. Ce projet est un terrain d'essai pour de futurs ajouts possibles à java.time. Vous trouverez peut - être des classes utiles ici, comme Interval, YearWeek, YearQuarteret plus .