Discussion :

[Pragmateek]

Salut!

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

Code :

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

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 :

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

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

et

Code :

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

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

provoquent le warning:

Code :

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

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.

[Aldebaranl2]

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

[osopardo]

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

[Pragmateek]

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

[had35]

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 :

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

1
2
3
4
 
Object clone() {
   return new ArrayList<Float>();
}

La méthode d'osopardo est la plus fiable

[adiGuba]

Salut,


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

Code :

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

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

a++

[Pragmateek]

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

[®om]

Salut,


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

Code :

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

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...

[adiGuba]

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 :

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

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++

[®om]

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

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

[adiGuba]

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++