Pourquoi l’API de date Java (java.util.Date, .Calendar) est-elle si désastreuse?

Question

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

Sur le dessus de ma tête:

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

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

Maintenant, ma question est:

Comment ces classes dans le SDK Java? La plupart de ces problèmes semblent assez évidentes (surtout Date mutable) et aurait été facile d'éviter. Alors, comment se fait-il? La pression du temps? Ou sont les problèmes évidents, rétrospectivement, seulement?

Je me rends compte que ce n'est pas strictement une question de programmation, mais je l'avais trouvé intéressant de comprendre comment la conception d'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 mieux que je ne pourrais jamais le dire:

java.util.Date est un témoignage du fait que, même brillante, les programmeurs peuvent bousiller. java.util.Calendar, où le Soleil autorisé à rectifier l' Date mess, est un témoignage du fait qu'en moyenne les programmeurs peuvent bousiller, trop.

(Ne me souviens pas qui est venu avec elle; merci d'éditer/commenter avec le devis original & source si vous connaissez).

Comme pour la mutabilité, beaucoup de le début des classes du JDK souffrir (Point, Rectangle, Dimension, ...). Mal acheminés optimisations, 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 la création de copies (o.setPosition(o.getPosition().add(5, 0))) comme vous l'avez fait avec immutables. Cela peut même avoir une bonne idée avec le début des VMs, alors qu'il est plus probable n'est pas moderne, avec des machines virtuelles.

Answer 2

Java du début de l'Api ne sont rien de plus qu'un produit de son temps. L'immutabilité n'est devenue un concept populaire des années après. Vous dites que l'immuabilité est "évidente". Cela pourrait être vrai aujourd'hui, mais il n'était pas à l'époque. Tout comme l'injection de dépendance est maintenant "évident", mais ce n'était pas il y a 10 ans.

Il a également été à la fois coûteux de créer un Calendrier des objets.

Ils restent en arrière pour des raisons de compatibilité. Ce qui est peut-être plus regrettable est qu'une fois que l'erreur a été réalisé à la vieille classe n'était pas obsolète et la nouvelle date/heure classes ont été créées pour toutes les Api d'aller de l'avant. C'est à un certain degré, s'est produite avec le JDK 7 adoption d'un JodaTime comme API, mais c'est vraiment trop peu, trop tard.

Answer 3

Le temps est lui-même pas facile à mesurer et à manipuler avec. Il suffit de regarder la longueur de l'article de wikipédia sur le temps. Et puis, il y a différentes compréhensions sur le temps lui-même: un absoulte point dans le temps (comme une constante), un point dans le temps à un certain endroit, un intervalle de temps, la résolution de l'heure....

Je me souviens, quand j'ai vu java.util.Date de la première fois (JDK 1.0?) j'ai été vraiment heureux à ce sujet. Les langues que je connaissais n'a pas eu une telle fonctionnalité. Je n'avais pas penser à la fois la conversion etc.

Je pense que c'est du gâchis, parce que tout ce que les changements laisse un mess si vous évoluer d'un niveau de compréhension (XMLGregorianCaldender vs Date) et les exigences (Nanosecondes, passé 2030) à un haut niveau, tout en gardant les anciens intacte. Et java.util.La Date n'est pas une Exception. Il suffit de regarder les I/O sous-système ou la transition de l'AWT pour Swing...

Et à cause de cela, "nous devons parfois, appuyez sur le bouton de réinitialisation." (qui a dit que, btw.?)

Answer 4

Vous pourriez trouver le post suivant intéressant. Cela explique à peu près comment la classe Calendar est entrée dans l'API Java et jette un éclairage sur les origines de la classe de date.

Les sept habitudes d'une conception extrêmement dysfonctionnelle