Dois-je utiliser java.util.Date ou passer à java.temps.LocalDate
Edit: Eh bien, apparemment c'était trop basé sur l'opinion, alors laissez-moi essayer de le reformuler plus précisément -
Y a-t-il des mises en garde ou des inconvénients clairs de l'utilisation de LocalDate, LocalTime, etc. dans un code Java qui n'a pas besoin de rétrocompatibilité, et si oui - quels sont-ils?
Je cherche des choses comme "Les bibliothèques EE actuelles X et Y ne fonctionnent pas correctement avec LocalDate" ou "Ce modèle très utile est cassé avec LocalTime" et cetera.
(voici l'original question de référence)
Avec Java 8, une nouvelle API temporelle est introduite, à savoir le java.temps.LocalDate etc. mais java.util.La date n'est pas marquée comme obsolète.
J'écris un nouveau projet, qui n'a pas besoin d'être rétrocompatible. Dois-je utiliser uniquement LocalDate, LocalDateTime, etc.? Y a-t-il des inconvénients à utiliser cette nouvelle API par opposition au bon vieux java.util.Date?
En particulier - je vais travailler principalement avec JDBC. D'après ce que j'ai vu les poignées JDBC Java.util.Date de bien. Est-il aussi bien adapté pour LocalDate?
La recherche a donné beaucoup de sites indiquant comment convertir d'un format à l'autre, mais aucune réponse définitive quant au nouveau code devrait utiliser l'ancienne API.
Merci.
1 answers
Malgré le nom, java.util.La date peut être utilisée pour stocker à la fois la date et l'heure (elle stocke le décalage en millisecondes UTC depuis l'époque)
J'utiliserais certainement la nouvelle API en raison de plus grandes fonctionnalités:
- Format/analyse plus facile. L'API a ses propres méthodes de format/analyse
- L'API inclut l'opération d'addition / soustraction (minusMinutes, plusDays, etc.)
Aucun de ce qui précède n'est disponible sur java.util.Date
Old Date peut également être converti en LocalDateTime comme ceci:
Date oldDate = ...
LocalDateTime newDateTime =
LocalDateTime.from(Instant.ofEpochMilli(oldDate.getTime()));