Discussion :

[CyberChouan]

J'utilise un service externe qui me renvoi un tableau d'objets. J'ai ensuite besoin de travailler sur ces données (ajout, suppression...). Je pense donc tout naturellement à transformer ce tableau en liste, bien plus facile à manipuler de manière "objet".

Je regarde donc si cette transformation n'est pas déjà fournie par Sun, pour ne pas réinventer la roue: bingo! Je tombe sur la méthode statique Arrays.asList(), que j'ajoute à mon code rapidement sans trop regarder plus loin.

Et c'est là que les soucis commencent... lorsque je veux supprimer des données de cette liste. Voici une simplification de ma méthode:

Code :

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

1
2
3
4
5
6
7
8
public removeObject(List l) {
   Iterator i = l.iterator();
   while(i.hasNext()) {
      if(estASupprimer(i.next())) {
         i.remove();
      }
   }
}

Jusque là, rien de choquant... (du moins j'espère). Si ce n'est que... ça ne marche pas avec une liste obtenue par Arrays.asList(): UnsupportedOperationException

En investiguant, j'ai trouvé l'explication:
Arrays.asList() renvoie une ArrayList... mais pas une java.util.ArrayList comme on a l'habitude de les utiliser. Elle renvoie une instance d'une classe interne: Arrays$ArrayList.

L'explication est donnée dans la javadoc: cette classe donne une liste de taille fixe (pas de méthodes add(), remove(), ...). Le tableau passé en paramètre à la création de la liste reste lié à celle-ci, et toute modification de la liste modifie en même temps le tableau associé. C'est cette contrainte qui impose la taille fixe.

Soit... mais bilan: je n'ai pas trouvé de classe native de Sun fournissant une méthode pour créer une liste à partir du tableau, tout en me permettant de manipuler librement celle-ci par la suite.

Si je n'ai pas suffisamment cherché, merci de me corriger.

Note: inutile de chercher... ce post ne contient pas de question (j'ai trouvé l'explication de mon unsupportedOperationException en lisant la javadoc). Ce post est juste là afin d'éviter que d'autres personnes ne fassent la même bétise que moi, en croyant (au père Noël) gagner du temps à ne pas lire comment se comporte une classe avant de l'utiliser.

PS: oui, il m'arrive encore parfois de rêver que des personnes feront une recherche avant de poster une question...

Moralité:

Code :

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

1
2
3
public static List getTrueListFromFalseList(List l) {
   return new ArrayList(l); // ou LinkedList au choix
}

[adiGuba]

Salut,



Si tu veux manipuler une vrai liste il faut que tu la crées :

Code :

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

	List<String> list = new ArrayList<String>( Arrays.asList(array) );

Ou mieux (on évite une classe intermédiaire) :

Code :

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

1
2
	List<String> list = new ArrayList<String>();
	Collections.addAll(list, array);

Je rappelle juste que la plupart des méthodes de l'interface Collection (et de ses sous-interfaces) sont optionnelles : il n'y a rien de choquant à ce qu'elle ne soit pas implémenté

a++

[CyberChouan]

Oui, merci. C'est également la conclusion à laquelle j'étais arrivé

[Duc Lebowski]

Juste pour ajouter une remarque sans grand intérêt :

Ce qui me pose vraiment problème avec le parcours des collections Java, c'est la méthode "remove" de Iterator qui throw une UnsupportedOperationException sur les objets pour lesquels elle ne peut s'appliquer.

Je trouve que c'est un gros problème de conception que d'offrir des fonctionnalités qui seront interdite à l'exécution, je ne comprends pas pourquoi il n'a pas été conçu un Iterator en lecture/seule et un Iterator en lecture/suppression...

Enfin bon, a priori ça ne va pas être revu tout de suite alors il va falloir s'y faire ou créer ses propres itérateurs en attendant...

[adiGuba]

Parce que ce problème ne se retrouve pas seulement pour la méthode remove() de l'iterator. Plusieurs méthodes des collections sont en effet optionnelles !



Déjà si on duplique l'interface Iterator afin d'avoir un ReadOnlyIterator il faudrait dupliquer aussi l'interface Collection et toutes ses sous interfaces, pour distinguer les Collections qui utiliserait un Iterator des "ReadOnlyCollections" qui utiliserait un ReadOnlyIterator...

Si on ajoute à cela les méthodes optionnelles de l'interface Collection (add(), addAll(), remove(), removeAll(), retainAll(), clear()) il faudrait déjà 8 interfaces différentes... ce qui n'est pas forcément mieux que la solution actuelle...


je ne sais pas s'il existe un pattern "propre" pour gérer des méthodes optionnelles...

a++

[Duc Lebowski]

On pourrait envisager Iterator extends ReadOnlyIterator et Collection extends ReadOnlyCollection, cela ne me choque pas du tout...

Mais bon les 2 points de vue son discutables, après c'est une question de goût et surtout de compromis