java.util.Date est-il obsolète ?

bonjour,

la classe Date m'est bien utile car c'est celle qui me permet d'exploiter des dates, venant d'une bdd, sans avoir à passer par un converter.
Seulement, ses methodes getXXX() sont toutes deprecated. Je veux bien accepter le changement, mais j'utilise quoi en attendant ?
...la classe Calendar ? ...et après, pour persister en base, je re-cast en Date ? :weird:

J'ai comme l'impression d'être passé à cotés de quelque chose de capital au sujet des dates, mais quoi ?

Salut,

En Java 8, l'API java.time permet de gérer les dates et autres éléments temporels de manières plus simple. Avant, il y avait l'API tierce JodaTime.

J'aurais tendance à penser que tu es passé à côté de SimpleDateFormat... mais je peux me tromper ;)

merci d'y répondre, joel.
Par contre, je me sens comme davantage embourbé dans la mélasse :aie:
En réalité, si les méthodes getXXX() fonctionnent encore dans 5 ans, mon problème est résolu ! ...mais la qualification "deprecated" ne me laisse pas serein.
D'un cotés, j'ai un bean Entity qui me deal du java.util.date ...et il faudrait que je transite par une autre classe pour exploiter les données que contiennent ces dates ?
Ce n'est pas le passage d'un format à l'autre qui me rebute, mais le fait de n'avoir pas d'autres choix.
Mon code n'est pas toujours propre, mais là ça fait carrément tâche.

@ Obutterlin,
merci je vais regarder ça ...mais je n'y crois plus trop, à vrai dire lol

En gros, j'ai l'impression que ton problème c'est la transition, entre l'époque de java.util.Date (et son faux jumeau maléfique Calendar), et l'époque du java.time. Une réflexion à priori partagée par ceux qui sont à l'origine de ce tutoriel. En attendant, la dépréciation n'empêche pas effectivement d'utiliser les méthodes dont tu parles. Je n'y connais rien à ce que tu appelles Entity (je suppose que ça a un rapport avec Hibernate ou un truc comme ça), et je ne perçois pas le problème comme toi : je n'ai simplement jamais utilisé de ma vie les getters de la classe java.sql.Date. Peut-être auras-tu des indices de réponse dans ce tutoriel à ce sujet.

Euh, je ne comprends pas ton problème là...
Les entity mappent facilement (et automatiquement) une java.sql.Date en java.util.Date... du coup, où est ton problème ?

Sinon, tu passes d'un type à l'autre très facilement par code

Code:

---

1 2 3 4

java.sql.Date sqlDate = new java.sql.Date(utilDate.getTime());   java.util.Date utilDate = new java.util.Date(sqlDate.getTime());

---

pour faire court, joel, je laisse JPA se charger du mapping : il me génère automatiquement mes @Entity à partir de la structure des tables de la bdd.
Un champ date, dans une des tables, me donne un attribut de type java.util.date dans l'entity qui correspond à cette table.
Je n'ai aucun contrôle (me semble-t-il) sur la façon dont JPA génère ces entity, et il fait le choix de java.util.date.
Cette classe date, elle me convient bien, elle fait le taf et tout
...mais ses get() sont étiquetés "deprecated" ...et en guise de solution de remplacement, on te propose de te prendre la tête, tout simplement ! :calim2:


@ Obutterlin
oui nickel, ça map bien, tranquille ...c'est juste l'étiquetage deprecated qui me pose problème
...parce que d'une certaine manière ça m'oblige à passer par un autre format de date pour faire ma cuisine, puis de repasser en util.date si je veux répercuter en base
Il n'y a que moi qui trouve ça crade ou quoi ? lol

Salut,


Il y a peu de chance que les méthodes dépréciées de la classe Date disparaissent, cela casserait trop de code.

Toutefois cela ne change rien au fait que l'API de la classe Date est toute pourrie !
Déjà elle n'est pas immuable, ce qui oblige à faire plein de copie défensive sous peine de provoquer des bugs.
Et elle représente une date au format GMT, mais ses méthodes l'adapte au timezone courant, ce qui peut être troublant dans certains cas.
Sans compté l'héritage bien particulier de tout cela (java.util.Date parent de sql.Date, sql.Time et sql.Timestamp alors que c'est des notion plutôt différente).
Et ne parlons même pas de Calendar...


:arrow: Tu gagnerais fortement à passer à la nouvelle API de Date !



Pour JPA apparemment il suffit de définir un convertisseur pour que le mapping soit automatique :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

public class LocalDateAttributeConverter implements AttributeConverter<LocalDate, java.sql.Date> {   @Override public java.sql.Date convertToDatabaseColumn(LocalDate localDate) { return (localDate == null ? null : java.sql.Date.valueOf(localDate)); }   @Override public LocalDate convertToEntityAttribute(java.sql.Date sqlDate) { return (sqlDate == null ? null : sqlDate.toLocalDate()); } }

---

Idem pour sql.Time/LocalTime et sql.Timestamp/LocalDateTime...


a++

Citation:

---

Envoyé par adiGuba

Pour JPA apparemment il suffit de définir un convertisseur pour que le mapping soit automatique :

---

Ce n'est même pas la peine de te casser la tête, l'annotation @Temporal marche très bien ;)

Code:

---

1 2 3 4 5 6 7

@Temporal(TemporalType.TIMESTAMP) @Column(name = "DISPLAY_END", length = 26) public Date getDisplayEnd() { return this.displayEnd; }

---

(avec TemporalType.DATE ou TemporalType.TIME)

Citation:

---

Envoyé par IDtalc

Il n'y a que moi qui trouve ça crade ou quoi ? lol

---

Ben, oui :mouarf:

Blague à part, personnellement, ça ne me pose aucun problème, et je n'utilise aucune méthode @Deprecated (là j'ai du mal à comprendre ce que tu fais si toi tu les utilises)
Le seul moment où on se pose la question de la représentation d'une date c'est dans l'IHM et là, en fonction de la techno utilisée, ce sera plus ou moins évident. Avec JSF c'est trivial (encore plus avec Primefaces)

...que de complications je trouve !
Je crois que je vais mettre cette affaire de cotés pour l'instant, car si il y a un choix à faire à ce niveau, je n'ai pas encore tous les éléments pour trancher.
J'espère seulement que je n'aurai pas à choisir quel fuseau horaire indiquait minuit lorsque jésus a trépassé ...
Il est clair que j'ai largement sous-estimé ce problème de date, pensant que tant que je me tenais à distance de l'horizon d'un trou noir je n'avais pas trop à m'en soucier. Que nenni !
N’interprétez pas, j'ai rien contre les black. Merci pour vos com, j'y reviendrai au moment opportun

bah y a pas vraiment super compliqué

Le vieux trucs mal ficelés d'il y a 20 ans

java.util.Date: contrairement à ce que son nom indique, c'est un timestamp absolu, indépendant de la position dans l'espace. à 10h00 en Angleterre et 11H00 en France, il est le même java.util.Date

java.sql.Date: type utlisé par jdbc pour mapper les colonne de type Date sql. C'est un java.util.Date dont on retire les heure comme on peu, parce qu'on ignore la timezone à utiliser
java.sql.Time: type utlisé par jdbc pour mapper les colonne de type Time sql. C'est un java.util.Date dont on retire les jour comme on peu, parce qu'on ignore la timezone à utiliser
java.sql.TimeStamp: type utlisé par jdbc pour mapper les colonne de type TimeStamp sql. C'est un java.util.Date

java.util.Calendar: api de manipulation de dates dans une timezone & calendrier (ajout / extraction d'heures, de jours, de semaines). Peut être mappé en jdbc vers des colonne "date/time/timestamp" ou "date/time/timestamp with timezone". On y retrouve un calendrier julien, un calendrier grégorien et d'autres calendriers bizarres dans des apis à part

Les nouveau trucs à préférer

LocalDate: une date, sans tenir compte de la timezone. Autrement dit, si je fais tourner un code à Paris et à Sidney, vers minuit, on aura pas la même valeur pour représenter la LocalDate. Exemple d'utilisation: une date d'anniversaire
LocalTime: une heure, sans tenir compte de la timezone. Exemple d'utilisation: une heure dans un planning simple: on mange à 13:00
LocalDateTime: une date + heure sans tenir compte de la timezone. Exemple: naissance: "né le 5/2/74 à 11:35"
OffsetDateTime: date + heure dans une timezone. Exemple d'utilisation: agenda: "rendez vous le 15/7/2016 à 13:00 UTC" qui est la même chose que "rendez vous le 15/7/2016 à 14:00 GMT+1", timestamp
Duration: une durée de temps exprimée en heures. Exemple: ce film dure 2h30:45s, le temps de travail réglementaire est de 38h00 par semaine,...
Period: une durée de temps exprimée en jour. Exemple: Ce projet est estimé à 6mois, et 15 jours. Cette personne à 25ans, 4mois et 24jours

Citation:

---

Envoyé par OButterlin

Ce n'est même pas la peine de te casser la tête, l'annotation @Temporal marche très bien ;)

---

Sauf erreur l'annotation @Temporal fonctionne seulement pour java.util.Date.

Les convertisseurs permettent de mapper avec les types de la nouvelles API de date (LocalDate, LocalTime, LocalDateTime...)


a++

Effectivement, ça ne fonctionne pas avec les nouveaux types (uniquement java.util.Date et java.util.Calendar), j'étais resté dans son problème de base :aie:
On est en retard ici, on tourne en java 7... ;)

la nouvelle api date de java 8, de manière assez logique, on verra surement arriver le support jpa pour cette api dans java EE 8, prévu si je ne m'abuse pour début 2017

Citation:

---

Envoyé par tchize_

Les nouveau trucs à préférer

LocalDate: une date, sans tenir compte de la timezone. Autrement dit, si je fais tourner un code à Paris et à Sidney, vers minuit, on aura pas la même valeur pour représenter la LocalDate. Exemple d'utilisation: une date d'anniversaire
LocalTime: une heure, sans tenir compte de la timezone. Exemple d'utilisation: une heure dans un planning simple: on mange à 13:00
LocalDateTime: une date + heure sans tenir compte de la timezone. Exemple: naissance: "né le 5/2/74 à 11:35"
OffsetDateTime: date + heure dans une timezone. Exemple d'utilisation: agenda: "rendez vous le 15/7/2016 à 13:00 UTC" qui est la même chose que "rendez vous le 15/7/2016 à 14:00 GMT+1", timestamp
Duration: une durée de temps exprimée en heures. Exemple: ce film dure 2h30:45s, le temps de travail réglementaire est de 38h00 par semaine,...
Period: une durée de temps exprimée en jour. Exemple: Ce projet est estimé à 6mois, et 15 jours. Cette personne à 25ans, 4mois et 24jours

---

Et il manque la classe Instant :)