¿Por qué la API de Java de fecha (java.util.Date, .Calendar) es un desastre?

Question

Como la mayoría de la gente está muy consciente de esto, la API de Java para manejar fechas de calendario (específicamente las clases java.util.Date y java.util.Calendar) es un desastre terrible.

De la parte superior de mi cabeza:

• fecha es mutable
• Fecha representa una marca de tiempo, no es una fecha
• hay manera fácil de convertir entre componentes de la fecha (día, mes, año .. .) y fecha
• Calendar es torpe para usar, y trata de combinar diferentes sistemas de calendario en una clase

This post lo resume bastante bien, y JSR-310 también expande estos problemas.

Ahora mi pregunta es:

¿Cómo estas clases convertirlo en el SDK de Java? La mayoría de estos problemas parecen bastante obvios (especialmente si la fecha es mutable) y deberían haber sido fáciles de evitar. Entonces, ¿cómo sucedió? ¿La presión del tiempo? ¿O son obvios los problemas solo en retrospectiva?

Me doy cuenta de que esto no es estrictamente una cuestión de programación, pero me parece interesante entender cómo el diseño de la API podría ir tan mal. Después de todo, los errores son siempre una buena oportunidad de aprendizaje (y tengo curiosidad).

Answer 1

Alguien puso mejor de lo que jamás podría decir que:

• Clase Date representa un instante específico en el tiempo, con milisegundo precisión. El diseño de esta clase es una broma muy mala: un aleccionador ejemplo de cómo incluso los buenos programadores se equivocan. La mayoría de los métodos en Fecha ahora están en desuso, reemplazados por métodos en las siguientes clases.

• Clase Calendar es una clase abstracta para la conversión entre un objeto Date y un conjunto de campos de enteros tales como año, mes, día, y hora.

• La clase GregorianCalendar es la única subclase de Calendar en el JDK. Hace las conversiones de fecha-campo para el sistema de calendario en el uso común .Sun licenció esta basura de oveja en exceso de Taligent, un aleccionador ejemplo de cómo los programadores promedio se equivocan.

de programadores Java FAQ, la versión de 07.X.1998, por Peter van der Linden - esta parte se retiró de las versiones posteriores sin embargo.

En cuanto a la mutabilidad, muchas de las primeras clases de JDK lo sufren (Point, Rectangle, Dimension, ...). Optimizaciones mal dirigidas, he escuchado algunas decir.

La idea es que desee poder reutilizar objetos (o.getPosition().x += 5) en lugar de crear copias (o.setPosition(o.getPosition().add(5, 0))) ya que tiene que ver con elementos inmutables. Esto incluso puede haber sido una buena idea con las primeras máquinas virtuales, aunque lo más probable es que no sea con las máquinas virtuales modernas.

Answer 2

Las primeras API de Java no son más que un producto de su tiempo. La inmutabilidad solo se convirtió en un concepto popular años después de eso. Usted dice que la inmutabilidad es "obvia". Eso podría ser cierto ahora, pero no fue entonces. Al igual que la inyección de dependencia ahora es "obvio", pero no fue hace 10 años.

También fue costoso en un momento crear objetos de calendario.

Siguen siendo así por razones de compatibilidad con versiones anteriores. Lo que es quizás más desafortunado es que una vez que se cometió el error, la clase anterior no se desaprobó y se crearon nuevas clases de fecha/hora para todas las API en el futuro. Esto se ha producido hasta cierto punto con la adopción de JDK 8 de una API tipo JodaTime (java.time, JSR 310), pero en realidad es demasiado poco y demasiado tarde.

Answer 3

El tiempo en sí mismo no es fácil de medir y manejar. Solo mira la longitud del artículo de wikipedia sobre time. Y luego, hay diferentes entendimientos sobre el tiempo mismo: un punto de tiempo absoulte (como una constante), un punto de tiempo en un lugar determinado, un intervalo de tiempo, la resolución de tiempo ....

Recuerdo, cuando yo vi java.util.Date la primera vez (JDK 1.0?) yo estaba realmente feliz por eso. Los idiomas que conocía no tenían esa característica. No pensé en la conversión de tiempo, etc.

Creo que es un desastre, porque todo lo que cambia deja un lío si evolucionas de un nivel de comprensión (XMLGregorianCaldender vs. Date) y requisitos (Nanoseconds, pasado 2030) a nivel superior, pero manteniendo intacto el viejo. Y java.util.Date no es una excepción. Basta con mirar el subsistema de E/S o la transición de AWT a Swing ...

Y debido a eso, "a veces deberíamos presionar el botón de reinicio". (¿Quién dijo eso, por cierto.?)

Answer 4

Puede encontrar la siguiente publicación interesante. Explica en gran parte cómo la clase Calendar ingresó a la API de Java en primer lugar, y arroja algo de luz sobre los orígenes de la clase de fecha.

The Seven Habits of Highly Dysfunctional Design