Discussion :

[yenox]

Bonjour,

Je viens de résoudre un problème d'affectation des variables dans une boucle for, et je me rends compte que je ne suis pas certain de comprendre ce qui se passe à 100%. Voici la boucle d'origine :

Code :

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

1
2
3
4
5
for(ObjetAssure objetAssure : listeObjetAssure){
		final ObjetAssure oA2 = objetAssureService.findById(objetAssure.getId());
		objetAssure = oA2;
 
}

Pour le contexte, la méthode appelée par le service se contente de retourner un nouvel objet eager alors que les objets de la liste sont lazy loaded via hibernate. Le problème était qu'à la sortie de la boucle les objets contenus dans la liste étaient inchangés.

Si je me contente par contre de simplement changer un attribut de l'objetAssure, il n'y a aucun problème, j'obtiens bien le résultat attendu, avec chaque élément de la liste modifié correctement.

Code :

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

1
2
3
for(ObjetAssure objetAssure : listeObjetAssure){
		objetAssure.setNumeroChrono("100");
}

J'ai résolu le problème avec la boucle suivante :

Code :

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

1
2
3
4
5
for(int i = 0; i < listeObjetAssure.size(); i++){
		final ObjetAssure oA2 = objetAssureService
				.findById(listeObjetAssure.get(i).getId());
		listeObjetAssure.set(i, oA2);
}

J'affecte ici directement l'objet retourné par le service dans la liste sans passer par un objet créé par la boucle de type foreach et ma liste est bien modifiée à la sortie de la boucle.

Je pensais que l'objetAssure de la boucle for pointait exactement à l'adresse de chaque objet de la liste et que par conséquent si j'affectais un nouvel objet à cette référence les objets contenus dans la liste seraient eux aussi modifiés. Visiblement mon raisonnement était faux, c'est pourquoi je fais appel à vos services pour m'éclairer quelque peu sur la portée et l'allocation des variables dans les boucles. Ce qui me perturbe le plus est le fait que ce raisonnement marche pour la modification d'attributs de l'objet mais pas pour la réaffectation complète de l'objet.

A noter que j'obtiens exactement les mêmes comportement avec des iterateurs explicites tels que :

Code :

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

1
2
3
4
5
6
final Iterator<ObjetAssure> i = listeObjetAssure.iterator();
while(i.hasNext()){
		ObjetAssure objetAssure = i.next();
		final ObjetAssure oA2 = objetAssureService.findById(objetAssure.getId());
		objetAssure = oA2;
}

Cordialement.

[joel.drigo]

Salut,

les variables java sont des pointeurs (on dit plutôt référence en java), mais modifier le contenu d'une variable ne modifie pas l'instance d'objet pointée, mais uniquement le contenu de la variable, donc elle ne fait que pointer vers une nouvelle instance d'objet.

Ainsi après l'éxécution de ce code,

Code :

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

1
2
Object o1=new Object(); // instance 1
o1=new Object(); // instance 2

l'instance 1 n'est pas remplacée en mémoire par l'instance 2. C'est juste que o1 contient la référence de l'instance 2 et non plus celle de l'instance 1 qu'elle contenait lorsqu'on l'a initialisée.

de même que

Code :

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

1
2
Integer i=2;
i=3;

ne fait pas que 2 prenne la valeur de 3 ! (heureusement )

[yenox]

Merci beaucoup. J'avais complètement oublié de brancher mon cerveau en me focalisant sur les itérateurs... C'est un peu honteux comme question du coup mais bon, la bêtise ne tue pas, parait-il.

[joel.drigo]

La bétise n'a rien à voir avec l'ignorance (ce n'est pas péjoratif hein ). Aucune connaissance n'est innée Et on apprend tous les jours... même ce qui peut paraître évident après coup.

[CrikTeCroque]

Et comme ce qui ne te tue pas te rend plus fort, tu es gagnant sur toute la ligne