Pourquoi la plupart des méthodes de java.util.Date ont-elles été dépréciées ?

Question

Lorsque vous regardez la javadoc de la classe java.util.Date, la plupart des méthodes sont dépréciées. Pourquoi cela a-t-il été fait ?

Answer 1

Eh bien, pour deux raisons liées. Il s'agissait d'une mise en œuvre très médiocre du concept de dates et d'heures et il a été remplacé par l'application Calendar classe.

En Calendar bien qu'elle constitue une amélioration, elle laisse également beaucoup à désirer. Ainsi, pour les travaux sérieux sur la date et l'heure, tout le monde recommande la classe Joda-Time . Java 8 apporte le nouveau paquet java.time.* inspiré de Joda-Time, défini par JSR-310 et destiné à remplacer les anciennes classes Date/Calendrier.

Edit : En réponse à la question spécifique de savoir pourquoi la mise en œuvre est mauvaise, il y a plusieurs raisons. La JavaDoc la résume comme suit :

Malheureusement, l'API de ces fonctions ne se prêtait pas à l'internationalisation.

En plus de cette déficience générale (qui couvre des questions telles que l'absence d'un composant de fuseau horaire ainsi que le formatage de la date qui est mieux géré dans le module DateFormat et l'impossibilité d'avoir une représentation du calendrier non grégorien), il y a des problèmes spécifiques qui nuisent vraiment à l'application de l Date notamment le fait que l'année est présentée avec un décalage de 1900 par rapport à l'année de l'ère commune.

Calendar a ses propres problèmes, mais même dès le JDK 1.1 il était évident que java.util.Date n'allait pas le couper. Même si Calendar est sans doute la pire API du JDK, il a fallu attendre la version 7 pour tenter de la résoudre.

Answer 2

• Date est mutable
• Date ne prend pas en charge les fuseaux horaires

Ce dernier a conduit à son remplacement par Calendar . Et les premiers, combinés à la facilité d'utilisation, ont conduit au remplacement des deux par Joda-Time / JSR-310 ( paquet java.time.* )

Answer 3

Ils sont dépréciés parce que Date a été écrit aussi vite que possible à l'époque où l'on voulait expédier le JDK par la porte.

Il s'avère que les dates et les calendriers sont durs. Ils ont donc créé la classe Calendar, qui est beaucoup plus réfléchie, afin de gérer les parties difficiles du travail avec les calendriers.

Ils ont déprécié les méthodes Date et les ont déléguées à Calendar parce qu'ils ne voulaient pas changer le comportement des méthodes Date existantes, et éventuellement casser les applications existantes.

Answer 4

Voici une bonne réponse provenant directement d'Oracle : http://www.oracle.com/technetwork/articles/java/jf14-date-time-2125367.html

Les développeurs Java ont longtemps été gênés par la prise en charge inadéquate des cas d'utilisation de la date et de l'heure par les développeurs ordinaires.

Par exemple, les classes existantes (telles que java.util.Date y SimpleDateFormatter ) ne sont pas thread-safe, ce qui entraîne des problèmes potentiels de concurrence pour les utilisateurs. Ce n'est pas un problème auquel le développeur moyen s'attend à être confronté lorsqu'il écrit du code de gestion des dates.

Certaines des classes de date et d'heure présentent également une conception d'API assez médiocre. Par exemple, les années dans java.util.Date commencent à 1900, les mois commencent à 1, et les jours commencent à 0 - pas très intuitif.

... java.util.Date représente un instant sur la ligne de temps - une enveloppe autour du nombre de milli-secondes depuis l'époque UNIX - mais si vous appelez toString(), le résultat suggère qu'il a un fuseau horaire, ce qui crée la confusion chez les développeurs.

Answer 5

Je ne connais pas la raison officielle pour laquelle il a été déprécié, mais pour autant que je puisse dire GregorianCalendar y Joda-Time prennent en charge les opérations sur les dates, ce qui signifie que vous pouvez ajouter, par exemple, un jour à une date et que le mois et l'année sont mis à jour en conséquence.

Par exemple, disons que vous voulez calculer le jour suivant la date actuelle et qu'aujourd'hui nous sommes le 31 mai ; avec java.util.Date vous avez juste getDays() +1 qui renvoie 32, et vous devez gérer vous-même le fait que le mois en cours ne compte pas 32 jours. GregorianCalendar ou Joda.time, l'ajout d'un jour au 31 mai donne lieu à un objet représentant le 1er juin, cachant la complexité à votre vue.