print new gregorian ejemplo convertir java date api-design

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



new calendar java (4)

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.

La parte superior de mi cabeza:

  • La fecha es mutable
  • La fecha representa una marca de tiempo, no una fecha
  • no es una forma fácil de convertir entre los componentes de fecha (día, mes, año ...) y Fecha
  • El calendario es difícil de usar e intenta combinar diferentes sistemas de calendario en una clase

Esta publicación lo resume bastante bien, y JSR-310 también expande estos problemas.

Ahora mi pregunta es:

¿Cómo llegaron estas clases al Java SDK? 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).

Alguien lo expresó mejor de lo que podría decirlo:

  • Class Date representa un instante específico en el tiempo, con una precisión de milisegundos. El diseño de esta clase es una broma muy mala, un ejemplo aleccionador 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 clases a continuación.

  • Class Calendar es una clase abstracta para convertir entre un objeto Date y un conjunto de campos enteros, como año, mes, día y hora.

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

de las preguntas más frecuentes de los programadores de Java , versión de 07.X.1998, por Peter van der Linden; sin embargo, esta parte se eliminó de las versiones posteriores.

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 quieras poder reutilizar objetos ( o.getPosition().x += 5 ) en lugar de crear copias ( o.setPosition(o.getPosition().add(5, 0)) ) como lo has hecho para hacer con 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.

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

Recuerdo, cuando vi java.util.Date la primera vez (¿JDK 1.0?) 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 un nivel superior, pero manteniendo el antiguo intacto. 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?)

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 java.time ( java.time , JSR 310) pero realmente es demasiado poco y demasiado tarde.