Discussion :

[IDtalc]

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 ?

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

[joel.drigo]

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.

[OButterlin]

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

[IDtalc]

merci d'y répondre, joel.
Par contre, je me sens comme davantage embourbé dans la mélasse
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

[joel.drigo]

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.

[OButterlin]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
java.sql.Date sqlDate = new java.sql.Date(utilDate.getTime());
 
java.util.Date utilDate = new java.util.Date(sqlDate.getTime());

[IDtalc]

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 !


@ 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

[adiGuba]

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...


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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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++

[OButterlin]

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

Ben, oui

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)