Pourquoi l'API Java Date (java.util.Date, .Calendar) un tel gâchis?

Question

Comme la plupart des gens sont douloureusement conscients de maintenant, l'API Java pour le traitement des dates du calendrier (en particulier les classes de java.util.Date et java.util.Calendar) sont un terrible gâchis.

Du haut de ma tête:

• La date est mutable
• La date représente un horodatage, pas une date
• pas facile de convertir entre les composants de date (jour, mois, année ...) et date
• Calendrier est maladroit d'utiliser, et tente de combiner différents systèmes de calendrier dans une classe

Ce message résume assez bien, et JSR-310 expains également ces problèmes.

Maintenant, ma question est la suivante:

Comment ces classes ont dans le SDK Java? La plupart de ces problèmes semblent assez évident (surtout date étant mutable) et aurait dû être facile à éviter. Alors, comment est-il arrivé? La pression du temps? Ou sont les problèmes évidents rétrospectivement seulement?

Je sais que ce n'est pas strictement une question de programmation, mais je trouve intéressant de comprendre comment la conception de l'API pourrait aller si mal. Après tout, les erreurs sont toujours une bonne occasion d'apprentissage (et je suis curieux).

Answer 1

Quelqu'un l'a dit mieux que je ne pourrais jamais dire:

  

  
• Date de classe représente un instant précis dans le temps, avec milliseconde   précision. La conception de cette classe est une très mauvaise blague - un qui donne à réfléchir   exemple de même de bons programmeurs bousiller. La plupart des méthodes   Date sont maintenant dépréciée, remplacées par des méthodes dans les classes ci-dessous.
  

• Classe Calendar est une classe abstraite pour convertir entre un Date   objet et un ensemble de champs entiers tels que l'année, le mois, le jour et l'heure.

  

• GregorianCalendar de classe est la seule sous-classe de Calendar dans le JDK.   Il fait les conversions date à-champs pour le système de calendrier en   usage commun. Sun sous licence cette ordure overengineered de Taligent - un   exemple qui donne à réfléchir de la façon dont la moyenne des programmeurs bousiller.

  

de Les programmeurs Java FAQ , la version de 07.X.1998, par Peter van der Linden -. Cette partie a été retirée de versions ultérieures si

En ce qui concerne la mutabilité, beaucoup des premières classes souffrent JDK (Point, Rectangle, Dimension, ...). optimisations Misdirected, j'ai entendu certains dire.

L'idée est que vous voulez être en mesure de réutiliser les objets (o.getPosition().x += 5) plutôt que de créer des copies (o.setPosition(o.getPosition().add(5, 0))) que vous avez à faire avec immutables. Cela peut même être une bonne idée avec le début des machines virtuelles, alors qu'il est le plus probable est pas avec les machines virtuelles modernes.

Answer 2

API Java de début ne sont plus qu'un produit de leur temps. Immuabilité n'est devenu un concept populaire années après. Vous dites que immuabilité est « évidente ». Cela pourrait être vrai maintenant, mais il n'a pas été là. Tout comme l'injection de dépendance est maintenant « évidente », mais il n'a pas été il y a 10 ans.

Il a également été à un moment donné cher pour créer des objets du calendrier.

Ils restent ainsi pour des raisons de compatibilité ascendante. Ce qui est peut-être plus regrettable qu'une fois l'erreur a été réalisée l'ancienne classe n'a pas été dépréciée et de nouvelles classes de date / heure ont été créés pour toutes les API à l'avenir. Cela a une certaine mesure a eu lieu avec le JDK 8 adoption d'une JodaTime comme API (java.time, JSR 310), mais vraiment il est trop peu trop tard.

Answer 3

Le temps lui-même est difficile à mesurer et à manipuler avec. Il suffit de regarder la longueur de l'article wikipedia sur le temps . Et puis, il y a des conceptions différentes sur le temps lui-même: un point de temps absoulte (comme une constante), un point de temps à un certain endroit, une plage de temps, la résolution du temps ....

Je me souviens, quand je l'ai vu la première fois java.util.Date (1.0 JDK?) J'étais vraiment heureux. Les langues que je connaissais de ne pas eu une telle fonction. Je n'avais pas penser etc conversion de temps.

Je pense qu'il est désordre, parce que tout ce qui change laisse un gâchis si vous évoluez d'un niveau de compréhension (XMLGregorianCaldender rapport à la date) et les exigences (nanosecondes, passé 2030) à un niveau supérieur, mais en gardant l'ancienne intacte. Et java.util.Date n'est pas une exception. Il suffit de regarder le sous-système E / S ou la transition entre AWT Swing ...

Et à cause de cela, « nous devons parfois appuyer sur le bouton de remise à zéro. » (Qui a dit que, d'ailleurs.?)

Answer 4

Vous trouverez peut-être le poste suivant intéressant. Il explique très bien comment la classe Calendar est entré dans l'API Java en premier lieu, et jette une certaine lumière sur les origines de la classe date.

Les sept habitudes de conception très dysfonctionnel