Aunque Joda tiene muchas funciones y es más sofisticado que el tiempo estándar de Java, puede que no siempre sea lo mejor. ¿Cómo decido si debo usar Joda Time o Java Time en algún código Java?

¿Existe algún tipo de directriz que nos indique cómo elegir la correcta según nuestros requisitos?

Joda Time es una mejora tan grande sobre la biblioteca de tiempo de Java que casi siempre es la elección correcta, aparte de las siguientes excepciones:

1. Cuando es difícil o indeseable agregar dependencias de terceros a su proyecto

2. Cuando su uso en una interfaz pública causaría problemas, por ejemplo, obtener un ORM para manejar los campos de tiempo de Java y Joda

Sin embargo, en el caso de 2) aún sería mejor usar Joda internamente si es posible.

Vale la pena tener en cuenta lo anterior, pero debería ser raro. En caso de duda, ve con Joda.

Tenga en cuenta que en el sitio web Joda-Time dice:

Las clases estándar de fecha y hora anteriores a Java SE 8 son deficientes. Al abordar este problema de frente, Joda-Time se ha convertido en la biblioteca de fecha y hora estándar de facto para Java. Tenga en cuenta que a partir de Java SE 8 en adelante, los usuarios deben migrar a java.time (JSR-310).

El principal contribuyente a Joda-Time , jodastephen , también es el principal contribuyente para JSR-310, como se puede ver en el repositorio de GitHub asociado con http://www.threeten.org/ . Por cierto, jodastephen también tiene un manejo SO ...

Creo que es seguro afirmar que podemos sentirnos cómodos y seguros con la nueva API de fecha y hora que se proporciona en Java 8 en adelante.

Algunas referencias adicionales:

• Página oficial JCP-310
• Joda-Time
• Tres diez
• java.time.* Javadoc
• Date Javadoc

La API de fecha estándar de Java está tan fundamentalmente rota que a menudo he considerado simplemente agregar Joda Time a las extensiones de la biblioteca de JVM para que se cargue en el classpath de forma predeterminada con el resto de la API de Java.

Si alguna vez se le ha asignado la tarea de actualizar la internacionalización y las zonas horarias en una aplicación Java heredada y ha intentado utilizar solo la API Java estándar, comprenderá lo que quiero decir. Pude convertir miles de líneas de código estúpidas en menos de cien. El aumento de la productividad es inconcebible.

Además, la API de fecha estándar no es intuitiva, donde la API de Joda fluida se puede recoger en horas, no en semanas. Su analogía de tratar de llegar a la isla que está a dos millas de distancia es más parecida a la siguiente.

1) Una lancha que lo llevará a la isla en solo 6 minutos.

O...

2) Una improvisada balsa de bambú atada con vides durante un huracán dirigido por un loco cuyo mejor amigo es el voleibol.

Como han dicho otras respuestas, los pocos inconvenientes, como el ORM, incluso se están volviendo inexistentes, ya que Hibernate ahora tiene complementos que permiten que las propiedades del bean tipo Joda se asignen a los campos de fecha / hora de la base de datos. JPA también podría tener una respuesta para esto también.

Si su deseo es que su aplicación tenga una huella minimalista como una aplicación de escritorio en lo que respecta al espacio en disco, entonces quizás Java ni siquiera sea la opción de idioma correcta.

Un punto más: Java-Time (es decir Date) no es ThreadSafe pero JodaTime sí. Por lo tanto, se prefiere JodaTime cuando los requisitos como

• Entorno multihilo que accede a los recursos comunes
• Sincronización de tiempo centralizada como situaciones

O bien, para aplicaciones simples, Java-Time está bien.

El marco java.time reemplaza tanto las clases de fecha y hora heredadas como Joda-Time

Actualización: las antiguas clases de fecha y hora incluidas con las primeras versiones de Java ahora son heredadas, suplantadas oficialmente por las clases java.time integradas en Java 8, Java 9 y versiones posteriores.

Date, Calendar, SimpleDateFormat, Y las java.sql.*clases de fecha y hora todos deben ser evitados. Nunca es necesario usar estas clases confusas, problemáticas y mal diseñadas. Están completamente reemplazados por clases java.time. Su único propósito ahora es mantener el código antiguo existente. Al interactuar con el código antiguo, puede convertir a / desde java.time llamando a nuevos métodos agregados a las clases antiguas. Para obtener más información sobre la conversión, consulte: Convertir java.util.Date a qué tipo de "java.time"? .

El proyecto Joda-Time , ahora en modo de mantenimiento , aconseja la migración a las clases java.time . El proyecto Joda-Time inspiró el marco java.time. Ambos están dirigidos por el mismo hombre, Stephen Colebourne . Puede pensar en java.time como una reescritura / rediseño de Joda-Time, todo código nuevo pero utilizando lo aprendido a lo largo de los años al construir la primera biblioteca de fecha y hora completa y sofisticada de la industria.

Para obtener más información, consulte el Tutorial de Oracle . Y busque Stack Overflow para obtener muchos ejemplos y explicaciones.

Gran parte de la funcionalidad java.time se transfiere a Java 6 y 7 en ThreeTen-Backport y se adapta aún más a Android en ThreeTenABP (consulte Cómo usar ... ).

El proyecto ThreeTen-Extra extiende java.time con clases adicionales. Este proyecto es un campo de pruebas para posibles adiciones futuras a java.time. Usted puede encontrar algunas clases útiles aquí, como Interval, YearWeek, YearQuarter, y más .