Discussion :

[hammajappa]

Salut j'ai un problème aux niveaux de date j'ai récupérer une date depuis Jcalendar (Jdatechooser)
mais je ne peux pas la stocker dans la base

Code :

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

1
2
pr.setDate_deb( dateDebut.getDate());
				pr.setDate_fin(datefin.getDate());

c deux ligne sont en rouge il me dit que set date n'est pas appicable sur java.util.date mais par contre sur java.sql.date
méme j'ai quand je veux convertir ces 2 variables(dateDebut et datefin) a travers ce code

Code :

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

1
2
3
java.util.Date utilDate = new java.util.Date();
				utilDate=dateDebut;
				java.sql.Date sqlDate = new java.sql.Date(utilDate.get));

il me dit que la variable utildate est de type java.util.date elle ne peut pas etre affécte a une variable de type Jdatechooser
je sais plus quoi faire

merciii =)

[yotta]

Bonsoir,
Etant donné que java.sql.Date est une sous-classe de java.util.Date, vous devriez pouvoir caster...
Avez-vous essayé ceci :

Code :

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

1
2
3
 
pr.setDate_deb( (java.sql.Date)dateDebut.getDate() );
pr.setDate_fin( (java.sql.Date)datefin.getDate() );

[joel.drigo]

Salut,

Je suppose que si tu as pu écrire :

Code :

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

1
2
pr.setDate_deb( dateDebut.getDate());
                pr.setDate_fin(datefin.getDate());

C'est que dateDebut n'est pas du type date, mais, probablement du type JDateChooser.

Donc tu ne peux pas écrire :

Code :

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

1
2
3
java.util.Date utilDate = new java.util.Date();
                utilDate=dateDebut;
                java.sql.Date sqlDate = new java.sql.Date(utilDate.get));

Puisque ça m'étonnerait que la classe JDateChooser étende java.util.Date (c'est un composant graphique, un JComponent). Sans parler de ce que j'ai mis en rouge, qui ne compilera pas : il n'existe aucun attribut (public ou pas) qui s'appelle get dans la classe java.util.Date.


Par ailleurs, on peut obtenir une variable de type java.sql.Date à partir d'une instance de java.util.Date, en faisant : new java.sql.Date(variableDuTypeDate.getTime()). L'inverse peut se faire directement par affectation, puisque java.sql.Date étend java.util.Date, mais on peut aussi écrire : new java.util.Date(variableDuTypeSQLDate.getTime())

[yotta]

Euh.. Hamajapa n'a jamais parlé de JDateChooser en terme de date, il a utilisé cet utilitaire qui permet de sélectionner graphiquement une date dans un contrôle graphique tout fait, mais comme il le dit lui-même :

c deux ligne sont en rouge il me dit que set date n'est pas appicable sur java.util.date mais par contre sur java.sql.date...

C'est qu'il utilise bien une instance de java.util.Date...
De plus, si dateDebut et dateFin sont des JDateChooser, la méthode getDate() de JDateChooser renvoie bien un java.util.Date, du moins d'après la documentation de l'API concernée.
Par contre, passer d'un java.util.Date a un java.sql.Date doit pouvoir être fait de plusieurs manières dont celles dont vous parlez joel.Drigo.
Du coup, comme je ne suis pas un grand spécialiste de la chose, est-ce que ma proposition de caster directement est possible ou pas ?

[joel.drigo]

Dans un fragment de son code, il appelle getDate() sur dateDebut, et dans l'autre il déclare une variable, utilDate, de type java.util.Date : or getDate() de java.util.Date (qu'il ne faut plus utiliser, par ailleurs) est du type int : donc de 2 choses l'une, soit il affecte un int à un java.util.Date, et donc il y a forcément une erreur de compilation suffisamment explicite pour qu'il change son code, soit dateDebut n'est pas un java.util.Date, mais plus probablement un JDateChooser, et donc ne peut être affecté à un java.util.Date, comme il tente de le faire dans l'autre fragment, pour lequel, il devrait également avoir une erreur de compilation, qui est probablement masquée par celle beaucoup plus évidente de la référence à un attribut get inexistant, à priori. Mais peut importe, quelque soit la configuration, il forcément une des lignes qui est en erreur, pour incompatibilité de type.

Maintenant, c'est sûr qu'avec des fragments de code disparates, il est difficile d'avoir un raisonnement sûr.

Si le problème est exposé correctement, il s'agit de récupérer deux dates saisies dans deux JDateChooser, dans le type java.util.Date, et de les transmettre à une méthode qui prend du java.sql.Date en paramètre. Et là, un cast ne sert à rien, si l'instance est de classe java.util.Date (ce qui est le cas avec un JDateChooser. IL n'y a aucune raison logique pour que cela soit du java.sql.Date). Un cast ne convertit pas : un cast spécialise. Pour spécialiser une variable typé java.util.Date vers du java.sql.Date, il faut que l'instance pointée par la variable soit de classe java.sql.Date. Sinon ClassCastException. Autrement dit, un java.sql.Date est un java.util.Date, mais un java.util.Date n'est pas forcément un java.sql.Date.

[joel.drigo]

Euh.. Hamajapa n'a jamais parlé de JDateChooser en terme de date, il a utilisé cet utilitaire qui permet de sélectionner graphiquement une date dans un contrôle graphique tout fait, mais comme il le dit lui-même :

c deux ligne sont en rouge il me dit que set date n'est pas appicable sur java.util.date mais par contre sur java.sql.date...

C'est qu'il utilise bien une instance de java.util.Date...

Ça j'avais bien compris que setDate_deb() (et setDate_fin, et pas "set date") attend du java.sql.Date et donc refuse qu'on lui passe un java.util.Date. Je parlais du second fragment de code, où on a un mélange de variables, de types, etc... en faisant référence au premier fragment, puisqu'on a une variable en commun (ce n'est pas impossible que ça soit 2 variables de même nom qui n'ont rien à voir, c'est sûr, mais bon, j'en doute).

[yotta]

Ok. Si j'ai bien tout compris, on peut caster un java.sql.Date en java.util.Date, mais pas l'inverse.
J'ai toujours eu des difficultés avec la notion d'héritage, je raisonnait à l'envers.
Mais bien que ce ne soit pas le cas ici (excusez moi d'abuser un peu), si on voulait transformer un java.sql.Date en java.util.Date on pourrait faire

Code :

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

1
2
 
java.util.Date DateTest  = (java.util.Date)truc;

truc étant évidement dans ce cas un java.sql.Date.
?

[joel.drigo]

Il n'y a pas besoin de caster quand on généralise un type.

Si truc est un java.sqlDate, on peut écrire directement :

Code :

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

java.util.Date dateTest  = truc;

Et ça ne transforme pas truc : l'objet référencé ("pointé") par dateTest sera toujours de la classe java.sql.Date.

Simplement, on le manipulera, via la variable dateTest, par le type java.util.Date. On ne pourra pas, par exemple appeler une méthode [codeinline]machin(java.sql.Date date)[/codeline] comme ça :

Code :

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

machin(dateTest);

Il faudra caster justement pour pouvoir l'appeler :

Code :

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

1
2
3
if ( dateTest instanceof java.sql.Date ) {
    machin((java.sql.Date)dateTest);
}

Et là non plus il n'y aura aucune transformation de l'instance référencée par la variable dateTest.

Lorsqu'on convertit une instance d'une classe vers une instance d'une autre classe, même s'il y a un lien hiérarchique entre les deux, il y a nécessairement un new quelque part (en mettant à part, bien sûr, les types primitifs, et l'autoboxing). Le new peut être déjà fait dans une méthode utilitaire de conversion, comme par exemple, la conversion de tableau en List, ou inversement, mais il y a un new.