Warning avec la méthode "clone" sur un "ArrayList"

Salut!:D

Pour copier le contenu d'un "ArrayList<ArrayList<Double>>", "matrice":

Code:

---

1 2 3 4 5 6

ArrayList<ArrayList<Double>> temp=new ArrayList<ArrayList<Double>>(); for(int i=0;i<matrice.get(0).size();i++){ temp=(ArrayList<ArrayList<Double>>)(matrice.clone());// for(int j=0;j<temp.size();j++){ temp.set(j,(ArrayList<Double>)(matrice.get(j).clone()));// }

---

.
Mais les lignes:

Code:

---

temp=(ArrayList<ArrayList<Double>>)(matrice.clone());

---

et

Code:

---

temp.set(j,(ArrayList<Double>)(matrice.get(j).clone()));

---

provoquent le warning:

Code:

---

Type safety: The cast from Object to ArrayList<ArrayList<Double>> is actually checking against the erased type ArrayList

---

Pourtant c'est bien ainsi que doit être casté le retour de "clone", non?

Merci de votre aide.:D

Je pense que nous montrer comment est construite ta matrice aiderait bien (quel type, quelle archi, etc..).

Deuxiemement, il est préférable d'utiliser une boucle "forEach" plutot qu'une boucle "for" dans ce cas :

for (ArrayList<ArrayList<Double>> al : matrice.get(0) {
............
}

et pareil pour la seconde ;)

Le transtypage et les types paramétrés ne font pas bon ménage pour le compileur, le seul moyen de se débarrasser de cet avertissement semble être la surcharge des méthodes clone pour qu'elles te retournent les types appropriés

Mais sinon il n'y a pas de risque de mauvais transtypage?
Le résultat est bien celui attendu?

Je pense que le warning vient du fait que le compilateur ne vérifie pas le type du template s'il est surcasté en Object. Le seul risque, mis à part l'inadvertance, est que si tu distribues ta librairie, un utilisateur ne comprenne pas la logique et outrepasse la méthode clone() pour retourner un objet qui ne serait pas du type requis. Le compilateur n'y verrait rien si cet objet est surcasté en Object.

Code:

---

1 2 3 4

Object clone() { return new ArrayList<Float>(); }

---

La méthode d'osopardo est la plus fiable ;)

Salut,


Il serait peut-être plus simple de créer une nouvelle ArrayList tout simplement :

Code:

---

temp = new ArrayList<ArrayList<Double>>(matrice);

---

a++

Adiguba=>C'est bon à savoir, merci.

Citation:

---

Envoyé par adiGuba

Salut,


Il serait peut-être plus simple de créer une nouvelle ArrayList tout simplement :

Code:

---

temp = new ArrayList<ArrayList<Double>>(matrice);

---

a++

---

C'est ce que j'allais dire :-)

D'ailleurs, je n'aime pas du tout le clone(), c'est stupide que cette méthode soit dans Object, elle devrait être dans l'interface Cloneable, avec un type paramétré...

Et par rapport à ce qui a été dit plus haut, surcharger la méthode clone() ne changerait rien au problème, vu que clone() retourne un Object, même en surchargeant il faut que ça retourne un Object...

Citation:

---

Envoyé par ®om

Et par rapport à ce qui a été dit plus haut, surcharger la méthode clone() ne changerait rien au problème, vu que clone() retourne un Object, même en surchargeant il faut que ça retourne un Object...

---

Ce n'est pas tout à fait vrai : depuis Java 5.0 on peut modifier le type de retour d'une méthode qu'on redéfini à condition que celui-ci soit assignable avec le type original.
Donc comme la méthode clone() retourne un Object, on peut la redéfinir afin qu'elle retourne n'importe quel autre type (sauf les primitifs bien entendu).

Ceci fonctionne très bien (et l'annotation @Override prouve qu'on redéfinie bien la méthode) :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

class MaClasse implements Cloneable { @Override public MaClasse clone() { try { MaClasse mc = (MaClasse) super.clone(); return mc; } catch (CloneNotSupportedException e) { throw new RuntimeException(e); } } }

---

Plus d'info dans la FAQ : Quelles sont les règles à respecter pour redéfinir/implémenter une méthode ?

Par contre il est vrai que cela n'est pas très adapté au cas présent...
a++

Ah, génial, je n'avais jamais vu ça dans java 1.5 !

Merci beaucoup, ça pourra être utile...

Et sur la même page, je viens de voir qu'il était possible de faire un switch sur une enum... Il me semblait avoir déjà essayé sans succès, mais là je viens de tester, effectivement ça a l'air de marcher :D

Sinon, tu ne trouves pas un peu bizarre le clone() qui est dans Object plutôt que dans Cloneable?

Citation:

---

Envoyé par ®om

Sinon, tu ne trouves pas un peu bizarre le clone() qui est dans Object plutôt que dans Cloneable?

---

La méthode clone() dans Object comporte tout le mécanisme de cloneage des objets, qui va s'occuper de créer une nouvelle instance (sans passer par le constructeur) et recopier tout ses attributs...

L'interface Cloneable est une interface marqueur qui indique qu'il est possible de cloner cette classe. Si cette interface n'est pas "implémenté", alors la méthode clone() de Object renverra une CloneNotSupportedException qui fera tout échouer... Si ta classe implémente Cloneable, cette exception ne sera jamais remonté par la méthode clone() de Object (c'est pourquoi j'ai "supprimé" l'exception avec un bloc try/catch + une RuntimeException).

Il y a un intérêt à cela : tu peux limiter l'utilisation de la méthode clone() car tu n'est pas obligé de la déclarer public (ce qui est le cas si elle vient d'une interface). Tu pourrais ainsi l'utiliser en interne dans ta classe dans d'autre méthode.


a++