ConcurrentModificationException dans une List

Version imprimable

Bonjour tout le monde.

J'ai un petit problème :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
 
import java.util.*;
 
class Thing { // simple classe qui contient un entier
	private int i;
	public Thing(int i) { this.i = i; }
	public String toString() {return "Thing " + i;}
}
 
public class Test2 {
	public static void main(String[] args) {
 
		List<Thing> lt = new ArrayList<Thing>(); // création et remplissage d'une List
		for(int i=0; i<6; i++) lt.add(new Thing(i));
 
		List<Thing> sub = lt.subList(2, 5); // on prend une sous-liste
		System.out.println(sub);
		lt.removeAll(sub); // et on la retire de la liste d'origine, ça foire ici
	}
}

J'ai fait ce programme basique et il me génère une ConcurrentModificationException .....

Code:

1
2
3
4
5
6
7
8
9
10
11
 
[Thing 2, Thing 3, Thing 4]
Exception in thread "main" java.util.ConcurrentModificationException
   at java.util.AbstractList$SubList.checkMod(libgcj.so.10)
   at java.util.AbstractList$SubList.listIterator(libgcj.so.10)
   at java.util.AbstractList.listIterator(libgcj.so.10)
   at java.util.AbstractList$SubList.iterator(libgcj.so.10)
   at java.util.AbstractCollection.contains(libgcj.so.10)
   at java.util.ArrayList.removeAllInternal(libgcj.so.10)
   at java.util.AbstractCollection.removeAll(libgcj.so.10)
   at Test2.main(Test2.java:18)

J'ai regardé dans la javadoc, ce genre d'exception est générée quand on utilise un iterator,
ce que je ne fais pas (en tout cas pas de façon apparente) ici.
quequ'un peut-il (elle) m'aider à résoudre le mystère?
Merci d'avance

19/09/2010, 19h13
adiGuba
Salut,

Cela n'arrive pas seulement avec les Iterators, mais le principe est un peu le même. Tout comme les Iterators, subList() retourne une vue sur la liste et non pas une copie.

Ces vues sont modifiables, et les modifications sont alors reportées sur la liste principale.

Par contre, les modifications sur la liste ne sont pas reporté sur les vues et provoque une ConcurrentModificationException. Ce choix est volontaire et permet d'avoir un code "fail-fast" (littéralement : qui plante rapidement). L'intérêt étant de ne pas utiliser de code qui pourrait entrainer des problèmes aléatoires.

:arrow: Il n'est pas impossible de gérer des modifications dans les deux sens, mais c'est assez compliqué et il est fort probable que plusieurs cas particulier ne soit pas géré. Pour éviter ce genre de problème les vues génèrent une exception dès qu'elles détectent une modification sur la collection liée...

Cela permet de rencontrer le problème très tôt en développement, et donc de prendre directement la meilleure solution !

Comme toujours dans ces cas là, la solution consiste à effectuer les modifications sur la vues. Elles seront automatiquement reportées sur la liste. Dans ton cas cela revient à faire ceci :
Code:

1 2 3 List<Thing> sub = lt.subList(2, 5); // on prend une sous-liste System.out.println(sub); sub.clear(); // et on la retire de la liste d'origine
a++
19/09/2010, 19h23
ChrisCondit

OKKAAAYYY !!!!!

Je vois clair maintenant.
:hola: Un grand merci à toi adiGuba pour cette réponse rapide et claire ! :mrgreen: