Sebbene Joda sia ricco di funzionalità e più sofisticato del tempo Java standard, potrebbe non essere sempre la cosa migliore da usare. Come faccio a decidere se utilizzare Joda Time o Java Time in qualsiasi codice Java?

Esiste una sorta di linea guida che ci dice come scegliere quella giusta in base alle nostre esigenze?

Joda Time è un tale miglioramento rispetto alla libreria temporale Java che è quasi sempre la scelta giusta, a parte le seguenti eccezioni:

1. Quando è difficile o indesiderabile aggiungere dipendenze di terze parti al progetto

2. Quando il suo utilizzo in un'interfaccia pubblica causerebbe problemi, ad esempio ottenere un ORM per gestire sia i campi di tempo java che quelli di Joda

Tuttavia, nel caso di 2) sarebbe comunque meglio usare Joda internamente se possibile.

Vale la pena ricordare quanto sopra, ma dovrebbe essere raro. In caso di dubbio, vai con Joda.

Si noti che sul sito Web di Joda-Time è indicato:

Le classi di data e ora standard precedenti a Java SE 8 sono scadenti. Affrontando questo problema frontalmente, Joda-Time è diventata di fatto la libreria standard di data e ora per Java. Da Java SE 8 in poi, agli utenti viene chiesto di migrare su java.time (JSR-310).

Il collaboratore principale di Joda-Time , jodastephen , è anche il collaboratore principale di JSR-310, come si può vedere nel repository GitHub associato a http://www.threeten.org/ . A proposito, jodastephen ha anche una maniglia SO ...

Penso che sia sicuro affermare che possiamo sentirci a nostro agio e al sicuro con la nuova API Data e ora come fornita da Java 8 in poi.

Alcuni riferimenti aggiuntivi:

• Pagina ufficiale JCP-310
• Joda-Time
• Tre-Ten
• java.time.* Javadoc
• Date Javadoc

L'API della data standard di Java è così fondamentalmente rotta che ho spesso considerato semplicemente l'aggiunta di Joda Time alle estensioni della libreria della JVM in modo che si caricasse sul percorso di classe per impostazione predefinita con il resto dell'API Java.

Se ti è mai stato assegnato il compito di retrofitting di internazionalizzazione e fusi orari in un'applicazione Java legacy e hai tentato di utilizzare solo l'API Java standard, capirai cosa intendo. Sono stato in grado di trasformare migliaia di righe di codice asinine in meno di un centinaio. L'incremento della produttività è inconcepibile.

Inoltre, l'API Date standard non è intuitiva, in cui l'API Joda fluida può essere prelevata in poche ore e non settimane. La tua analogia con il tentativo di raggiungere l'isola a due miglia di distanza è più simile alla seguente.

1) Un motoscafo che ti porterà sull'isola in soli 6 minuti.

O...

2) Una zattera di bambù improvvisata legata insieme a viti durante un uragano guidato da un pazzo il cui migliore amico è una pallavolo.

Come hanno affermato altre risposte, i pochi inconvenienti come ORM stanno persino diventando inesistenti poiché Hibernate ora ha plug-in che consentono di mappare le proprietà del bean di tipo Joda sui campi data / ora del database. Anche l'APP potrebbe avere una risposta per questo.

Se il tuo desiderio è che la tua applicazione abbia un footprint minimalista come applicazione desktop per quanto riguarda lo spazio su disco, allora forse Java non è nemmeno la scelta della lingua giusta.

Un altro punto: Java-Time (ovvero Date) non è ThreadSafe ma JodaTime lo è. Quindi JodaTime è preferito quando i requisiti lo richiedono

• Ambiente multi-thread che accede alle risorse comuni
• Sincronizzazione temporale centralizzata come situazioni

Oppure per semplici applicazioni Java-Time va bene.

Il framework java.time sostituisce sia le classi data-ora legacy che Joda-Time

Aggiornamento: le vecchie classi data-ora fornite con le prime versioni di Java sono ora legacy, soppiantate ufficialmente dalle classi java.time integrate in Java 8, Java 9 e versioni successive.

Date, Calendar, SimpleDateFormat, E le java.sql.*classi data-ora dovrebbero essere evitati. Non è mai necessario utilizzare queste classi confuse, problematiche, mal progettate. Sono interamente sostituiti da classi java.time. Il loro unico scopo ora è mantenere il vecchio codice esistente. Quando si interfaccia con il vecchio codice, è possibile convertire in / da java.time chiamando i nuovi metodi aggiunti alle vecchie classi. Per ulteriori informazioni sulla conversione, consultare: Convertire java.util.Date in quale tipo di "java.time"? .

Il progetto Joda-Time , ora in modalità manutenzione , consiglia la migrazione alle classi java.time . Il progetto Joda-Time ha ispirato il framework java.time. Entrambi sono guidati dallo stesso uomo, Stephen Colebourne . Puoi pensare a java.time come a una riscrittura / riprogettazione di Joda-Time, tutto il nuovo codice ma usando ciò che era stato appreso nel corso degli anni dalla costruzione della prima libreria di data-ora completa e sofisticata del settore.

Per saperne di più, consulta il tutorial Oracle . E cerca Stack Overflow per molti esempi e spiegazioni.

Gran parte della funzionalità java.time è trasferita su Java 6 e 7 in ThreeTen-Backport e ulteriormente adattata ad Android in ThreeTenABP (vedi Come usare ... ).

Il progetto ThreeTen-Extra estende java.time con classi aggiuntive. Questo progetto è un banco di prova per possibili aggiunte future a java.time. Si possono trovare alcune classi utili, come per esempio Interval, YearWeek,YearQuarter e altro .