Pourquoi la «nouvelle date (année int, mois int, jour int)» est-elle déconseillée?
Mon application dont j'ai récemment hérité est PLEINE d'avertissements de dépréciation concernant le constructeur:
Date d = new Date(int year, int month, int day)
Est-ce que quelqu'un sait ou peut indiquer une raison pour laquelle quelque chose d'aussi simple que cela a été "remplacé" par quelque chose comme ceci:
Date d = null;
Calendar cal = GregorianCalendar.getInstance();
cal.set(1900 + year, month, day);
d = cal.getTime();
Maintenant, les avertissements de dépréciation ne sont évidemment pas un problème en eux-mêmes, mais pouvez-vous imaginer les millions de LOC qui pleureraient à l'agonie si ce constructeur était supprimé?
Dans mon bref petit jeu de benchmarking, ce dernier prend environ 50% de temps de plus à exécuter.
À l'origine, Date était censé contenir toute la logique concernant les dates, mais les concepteurs d'API ont finalement réalisé que l'API qu'ils possédaient jusqu'à présent était terriblement inadéquate et ne pouvait pas être proprement étendue pour traiter correctement des problèmes tels que les fuseaux horaires, les paramètres régionaux, différents calendriers, heures d'été, etc.
Ils ont donc créé Calendar pour faire face à toute cette complexité, et relégué Date à un simple horodatage, dépréciant toutes ses fonctionnalités concernant le formatage, l'analyse et les champs de date individuels.
BTW, en interne ces méthodes telles que le constructeur Date(int, int, int) appellent maintenant Calendar, donc si vous voyez une différence de vitesse, alors vous faites quelque chose de mal lors de l'appel de Calendar.
L'essentiel: ce n'est pas l'API Calendar de Java qui est trop complexe, c'est le concept humain des dates, et le seul problème avec Calendar est qu'il n'offre pas beaucoup de raccourcis au maximum usages courants.
Les API Java Date ont longtemps été critiquées, voir par exemple ce fil .
Vous voudrez peut-être consulter Joda-Time ou Apache Commons Lang pour d'autres utilitaires de date/heure.
La réponse est la portabilité.
La classe Date n'est pas très flexible. Vous pouvez définir des dates, mais sans aucune transformation dans d'autres formats de calendrier. Sun a donc décidé d'utiliser une hiérarchie de classes supplémentaire (Calendar) pour la rendre plus flexible.
Néanmoins, ce n'est pas très pratique.
Principalement parce que le Java.util.Date d'origine était gonflé et n'était pas complètement sensible au fuseau horaire et n'était pas convivial pour l'internationalisation.
Cependant, Date est toujours utilisé et très bien, dans Value Objects, ou disons comme type de données. Dans la mesure où vous le rendez explicitement immuable, vous pouvez aller facilement. J'ai tendance à penser qu'il doit être immuable, à d'autres fins, nous avons le calendrier à manipuler. Là où son lot de manipulations était attendu, on devrait envisager quelque chose comme Joda-Time.
[Modifié]
N'instanciez simplement pas la date, dans ce dernier code. Ce n'est d'aucune utilité. Vous pouvez obtenir un meilleur résultat pour votre référence.
Bien sûr, personne n'utilise jamais d'autre format de calendrier, mais la nouvelle API augmente la quantité de code à écrire pour le cas courant à 99%, c'est donc une aubaine pour Java programmeurs payés par LoC.
Techniquement, Michael Borgwardt avait la meilleure réponse. Mais pourquoi blâme-t-il les humains pour la façon dont notre système solaire est disposé?
OK, nous avons eu l'idée des secondes, des minutes et des heures.
Mais ce n'est pas de notre faute si le jour de la Terre est approximatif (selon que nous parlons de vrai jour solaire, de jour solaire moyen ou de jour stellaire, chacun variant périodiquement et de manière aléatoire). Ce n'est pas de notre faute si l'heure de l'orbite de la Terre autour du Soleil est environ 365 jours, et ce n'est pas de notre faute si l'orbite de la lune autour de la Terre est environ 27,3 jours (selon que nous parlons d'un mois sidéral, synodique, tropical, anormal ou draconique (nodique)).
N'êtes-vous pas content que Calendar n'ait pas pris en compte tous ces détails? Ensuite, nos bogues logiciels pourraient en effet dépendre de la phase de la lune.