Perché la conversione tra Instant e Date è stata indicata come era?

Question

Perché la conversione tra Instant e Date è stata indicata come era?

#1 da (8 voti)

6

Quando Instant è stato introdotto con JSR-310, sono stati aggiunti metodi di convenienza per eseguire la conversione tra Date e Instant :

Date input = new Date();
Instant instant = input.toInstant();
Date output = Date.from(instant);

Mi chiedo perché sia stato scelto in questo modo invece di, diciamo, con Date output = instant.toDate() . La mia ipotesi è che si intendesse evitare di rendere Instant dipendente da Date . È giusto?

Ma per me è in qualche modo strano che tu rendi la nuova classe indipendente da quella già esistente, e rendi la vecchia dipendente da quella appena introdotta. Questo è reso così a causa di una previsione di deprecazione di Date o c'è qualche altra ragione?

api-design java

posta mark951131b 05.01.2016 - 12:23

fonte

1 risposta

Leggi altre domande sui tag api-design java

Usa StringLike invece di String in Scala? Implementazione della logica comune nella classe base

score 8 · Accepted Answer

Problemi con Date :

È un oggetto mutevole
Non è thread-safe
il costo di utilizzarlo in modalità thread-safe (sincronizzata) è costoso

Instant d'altra parte è progettato per essere thread-safe e immutabile. Rendere l'oggetto Immutabile è già di per sé un modo semplice ed economico per garantire la sicurezza del filo. Il Javadoc per Instant afferma:

Implementation Requirements:
This class is immutable and thread-safe.

Ora se vuoi fare qualcosa come Instant t = Instant.from(new Date()) , ciò significa che gli implementatori dell'API dovrebbero introdurre la sincronizzazione per garantire l'accesso sicuro ai thread dell'oggetto Date .

Ho il sospetto che volessero semplicemente avere una rottura netta con i vecchi metodi ed evitare di introdurre metodi espliciti sincronizzati. L'introduzione di metodi sincronizzati avrebbe suggerito che è giusto usarli. Anche se potrebbe essere utile avere, sarebbe l'impostazione di un brutto precedente.

Invece, hanno scelto di mantenere la conversione di Date in Instant all'interno dell'API Date , che non documenta alcuna sicurezza del thread. L'ipotesi di sicurezza è che spetta all'utente sincronizzare prima l'accesso all'oggetto Date , se richiesto.