2009-01-20 11 views
58

Mi aplicación que he heredado recientemente está llena de advertencias de desaprobación sobre el constructor:¿Por qué "nueva fecha (int año, mes int, día int)" obsoleta?

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

¿Alguien sabe o puede apuntar a una razón de por qué algo tan simple como esto fue "sustituido" con algo como esto:

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

Ahora, obviamente, las advertencias de desaprobación no son un problema en sí mismas, pero ¿pueden imaginarse los millones de LOC que estarían gritando en agonía si este constructor se elimina alguna vez?

En mi pequeño juego breve en el benchmarking, este último tarda aproximadamente un 50% más de tiempo en ejecutarse.

+4

¿No es la primera línea una pérdida total de tiempo? Usted obtiene una fecha de la llamada a Calendar.getTime(), entonces, ¿por qué crear una con la nueva llamada Date() que luego se descarta? Especialmente si estuvieras evaluando esto ... – unwind

+2

@ unwind: Una buena captura. por qué no, haz una publicación. –

+40

Quizás es porque los estadounidenses esperaban Fecha (int año, int día, mes int) ;-) – Skizz

Respuesta

48

Originalmente, Date estaba destinado a contener toda la lógica relativa a las fechas, pero los diseñadores de API finalmente se dieron cuenta de que la API que tenían hasta ahora era lamentablemente inadecuada y no podía extenderse limpiamente para tratar problemas tales como zonas horarias, locales, diferentes calendarios, tiempos de horario de verano, etc.

Así que crearon Calendar para hacer frente a toda esa complejidad, y relegados Date a una simple marca de tiempo despreciando todas sus funcionalidades que se ocupa de formato, analizar y campos de fecha individuales.

Por cierto, estos métodos internamente como constructor de Date(int, int, int) ahora llaman Calendar, así que si usted ve una diferencia en la velocidad, entonces usted está haciendo algo mal cuando se llama a Calendar.

La línea de fondo: No es Calendar API de Java que es demasiado complejo, es el concepto humano de fechas, y el único problema con Calendar es que ofrece no mucho en el camino de accesos directos a los usos más comunes.

+0

'java.util.Date' reutiliza una instancia estática del Calendario Gregoriano. Lo cual es interesante por decir lo menos. Pero funcionará mejor que la creación de un nuevo calendario para cada ciclo. – Martin

7

La respuesta es la portabilidad.

La clase Date no es muy flexible. Puede definir fechas, pero no con ninguna transformación a otros formatos de calendario. Entonces Sun decidió usar una jerarquía de clases adicional (Calendar) para hacerlo más flexible.

Sin embargo, no es muy útil.

8

Las API de fecha de Java se han criticado durante mucho tiempo; consulte, por ejemplo, this thread.

Es posible que desee comprobar Joda-Time o Apache Commons Lang para las utilidades alternativas de fecha y hora.

+0

Recuerdo ver una presentación sobre Joda en Parleys hace un tiempo y quedar impresionado. http://www.parleys.com/display/PARLEYS/Home#slide=1;title=JSR%20310%20-%20Date%20and%20Time%20API;talk=7602357. En cuanto a una implementación retro en 100s de 1000 o LOC, no estoy tan seguro. –

5

Principalmente porque el java.util.Date original estaba hinchado y no era completamente compatible con la zona horaria y no con la internacionalización.

Sin embargo, Date está todavía en uso y muy bien, en Value Objects, o como un tipo de datos. En la medida en que lo haces inmutable explícitamente, puedes ir con facilidad. Tiendo a pensar que debe ser inmutable, para otro fin tenemos que manipular el Calendario. Donde se espera su gran cantidad de manipulación, uno debería considerar algo como, Joda-Time.

[Editado]

Simplemente no lo crea la fecha, en este último código. No sirve de nada. Puede lograr un mejor resultado para su punto de referencia.

3

Por supuesto, nadie utiliza ningún otro formato de calendario, pero la nueva API aumenta la cantidad de código para escribir para el 99% de casos comunes, por lo que es una gran ventaja para los programadores de Java pagados por LoC.

+0

HA, seguramente en este día y edad LoC no se usa como una medida de productividad? –

+0

Uno esperaría que no, pero tal vez los capítulos de Sun que siguen produciendo API como esta no han escuchado que las cosas hayan cambiado ... – bobince

3

Michael Borgwardt tenía la mejor respuesta, técnicamente. ¿Pero por qué está culpando a los humanos por la forma en que nuestro sistema solar está diseñado?

Bien, se nos ocurrió la idea de segundos y minutos y horas.

Pero no es culpa nuestra que el día de la Tierra sea aproximado (dependiendo de si estamos hablando de día solar real, día solar medio o día estelar, cada uno de los cuales varía periódicamente y al azar). No es nuestra culpa que el tiempo de la órbita de la Tierra alrededor del Sol sea aproximadamente 365 días, y no es culpa nuestra que la órbita lunar alrededor de la Tierra sea aproximadamente 27.3 días (dependiendo de si estamos hablando de un mes sideral, sinódico, tropical, anómalo o draconiano (nodical) mes).

¿No te alegra que Calendar no haya tenido en cuenta todos esos detalles? Entonces nuestros errores de software podrían de hecho depender de la fase de la luna.

+0

Capitán Obvio ataca de nuevo! No es necesario copiar, solo señalar. http://en.wikipedia.org/wiki/Gregorian_calendar – IceGlow

Cuestiones relacionadas