Pourquoi "nouvelle date (int année, int mois, int jour)" est-il déconseillé?

Question

Mon application j'ai récemment hérité est PLEIN de la dépréciation des avertissements au sujet du constructeur:

Date d = new Date(int year, int month, int day)

Personne ne sait ou ne peut pointer vers une raison pourquoi quelque chose d'aussi simple que cela a été "remplacé" avec quelque chose comme ceci:

Date d = null;
Calendar cal = GregorianCalendar.getInstance();
cal.set(1900 + year, month, day);
d = cal.getTime();

Maintenant, évidemment, la dépréciation avertissements ne sont pas un problème en soi, mais pouvez-vous imaginer les millions de LOC qui serait de crier à l'agonie si ce constructeur n'a jamais été supprimé?

Dans ma brève peu de jeu à l'analyse comparative, ce dernier prend environ 50% plus de temps à s'exécuter.

Answer 1

À l'origine, Date a été destiné à contenir toute logique concernant les dates, mais l'API concepteurs fini par se rendre compte que l'API qu'ils avaient jusqu'à présent était tout à fait insuffisantes et ne pouvait pas être proprement étendus pour faire face correctement à des questions comme les fuseaux horaires, les lieux, les différents calendriers, le jour des économies de temps, etc.

Ils ont donc créé Calendar pour traiter toute cette complexité, et relégué Date d'un simple timestamp, rendant l'ensemble de ses fonctionnalités, qui traitait de mise en forme, l'analyse et l'individu champs de date.

BTW, en interne, ces méthodes telles que l' Date(int, int, int) constructeur appelle maintenant Calendar, donc si vous voyez une différence dans la vitesse, alors vous êtes en train de faire quelque chose de mal lors de l'appel d' Calendar.

La ligne de fond: Ce n'est pas de Java Calendar API qui est trop complexe, c'est le concept humain de dates, et le seul problème avec Calendar est qu'il n'offre pas beaucoup dans la façon de raccourcis pour les utilisations les plus courantes.

Answer 2

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 Date / Time.

Answer 3

La réponse est la portabilité.

La classe Date n'est pas très flexible. Vous pouvez définir des dates, mais pas avec une 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.

Answer 4

Principalement parce que l'original de java.util.La Date était gonflé et pas complètement le fuseau horaire courant et pas internationalisation sympathique.

Toutefois, la Date est encore en cours d'utilisation et très bien, dans des Objets de Valeur, ou de dire comme un type de données. Aussi loin que vous le rendre immuable explicitement, vous pouvez aller avec facilité. J'ai tendance à penser qu'il doit être immuable, pour d'autres raisons que nous avons de Calendrier à manipuler. Où son lot de manipulation attendu, on doit considérer quelque chose comme, Joda-Time.

[Édité]

Il suffit de ne pas instancier la Date, dans ce dernier code. Sa ne sert à rien. Vous pouvez obtenir un meilleur résultat pour votre référence.

Answer 5

Bien sûr, personne n’utilise jamais d’autre format de calendrier, mais la nouvelle API augmente la quantité de code à écrire pour le scénario courant à 99%. C’est donc un avantage considérable pour les programmeurs Java payés par LoC.