Perché era & # 8220; nuova data (int year, int month, int day) & # 8221; deprecato?

Question

La mia applicazione che ho ereditato di recente è COMPLETA di avvisi di deprecazione sul costruttore:

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

Qualcuno sa o può indicare un motivo per cui qualcosa di così semplice è stato "sostituito"? con qualcosa del genere:

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

Ora, ovviamente, gli avvisi di deprecazione non sono un problema in sé, ma puoi immaginare i milioni di LOC che griderebbero in agonia se questo costruttore fosse mai rimosso?

Nel mio breve gioco di benchmarking, quest'ultimo richiede circa il 50% in più di tempo per essere eseguito.

Answer 1

Inizialmente, Date doveva contenere tutta la logica relativa alle date, ma i progettisti dell'API alla fine si resero conto che l'API che avevano finora era terribilmente inadeguata e non poteva essere estesa in modo chiaro per affrontare correttamente problemi come come fusi orari, locali, calendari diversi, ora legale, ecc.

Quindi hanno creato Calendar per gestire tutta quella complessità e hanno relegato Date in un semplice timestamp, deprecando tutte le sue funzionalità che si occupavano di formattazione, analisi e singoli campi della data .

A proposito, internamente questi metodi come Date (int, int, int) ora il costruttore chiama Calendar , quindi se vedi una differenza di velocità, allora sei fare qualcosa di sbagliato quando si chiama Calendar .

La linea di fondo: non è l'API Calendar di Java che è eccessivamente complessa, è il concetto umano di date e l'unico problema con Calendar è che non offre molto in la via delle scorciatoie per gli usi più comuni.

Answer 2

Le API Java Date sono state a lungo criticate, vedi ad esempio questa discussione .

Potresti voler dare un'occhiata a Joda-Time o Apache Commons Lang per utilità alternative di data / ora.

Answer 3

La risposta è la portabilità.

La classe Date non è molto flessibile. È possibile definire le date, ma non con alcuna trasformazione in altri formati di calendario. Quindi Sun ha deciso di utilizzare una gerarchia di classi aggiuntiva ( Calendar ) per renderla più flessibile.

Tuttavia, non è molto utile.

Answer 4

Principalmente perché l'originale java.util.Date era gonfio e non completamente consapevole del fuso orario e non adatto all'internazionalizzazione.

Tuttavia, Date è ancora in uso e molto bene, in Oggetti valore, o diciamo come tipo di dati. Per quanto lo rendi immutabile esplicitamente, puoi andare con facilità. Tendo a pensare che debba essere immutabile, per altri scopi abbiamo Calendario da manipolare. Dove ci si aspettava molta manipolazione, si dovrebbe considerare qualcosa come Joda-Time.

[Modificato]

Basta non creare un'istanza della Data, in quest'ultimo codice. Non serve a niente. Puoi ottenere un risultato migliore per il tuo benchmark.

Answer 5

Naturalmente, nessuno usa mai nessun altro formato di calendario, ma la nuova API aumenta la quantità di codice da scrivere per il caso comune del 99%, quindi è un grande vantaggio per i programmatori Java pagati da LoC.

Answer 6

Michael Borgwardt ha avuto la migliore risposta, tecnicamente. Ma perché sta incolpando gli umani del modo in cui è strutturato il nostro sistema solare?

OK, ci è venuta l'idea di secondi, minuti e ore.

Ma non è colpa nostra se quel giorno della Terra è approssimativo (dipende dal fatto che stiamo parlando di vero giorno solare, giorno solare medio o giorno stellare, ognuno dei quali varia periodicamente e in modo casuale). Non è colpa nostra se il tempo dell'orbita terrestre attorno al Sole è approssimativamente 365 giorni, e non è colpa nostra se l'orbita lunare intorno alla Terra è approssimativamente 27,3 giorni (a seconda che si tratti di un mese siderale, sinodico, tropicale, anomalistico o draconico (nodico)).

Non sei contento che Calendar non abbia preso in considerazione tutti quei dettagli? Quindi i nostri bug del software potrebbero effettivamente dipendere dalla fase lunare.