Instanciation d'un tableau d'éléments de type générique

Version imprimable

Bonjour,

J'essaye d'instancier un tableau d'éléments de type générique T dans une constructeur d'une classe générique :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 class Plan<T> { public Plan(T[][] plan) { this.plan = plan; } public Plan(int yTaille, int xTaille, int valeurParDefaut) { plan = new T[yTaille][xTaille]; } public T recevoirElement(int y, int x) { return plan[y][x]; } public int recevoirLargeur() {return xTaille;} public int recevoirHauteur() {return yTaille;} private T[][] plan; private int yTaille, xTaille; }
L'erreur est ligne 9. Je sais pourquoi cela est interdit (limitation de la programmation générique en Java ; T est en fait remplacé par Object), mais j'aimerais bien contourner cette limitation. Je peux procéder ainsi :

Code:

plan = (T[][]) new Object[yTaille][xTaille];

Mais ce n'est pas très propre et il reste un panneau attention à la compilation.

Merci d'avance !

02/12/2013, 19h28
tchize_

Et surtout ça ne marchera pas quand tu remontera un cran plus haut et que tu castera ton T[][] en, par exemple, Integer[][] car la jvm te lancera un ClassCastException (un Integer[][] n'est pas la même chose qu'un Object[][]).

Le problème ici est le même que l'impossibilité de faire un new T(). La seule solution de contournement, c'est qu'on te passer une instance de T[][] et que, éventuellement, tu l'agrandisse. C'est ce que fait la classe ArrayList, dont je te suggère d'aller voir la méthode "T[] toArray(T[])" qui en dit long sur ce problème de generic et de tableau :)
02/12/2013, 19h44
collect

Ah, mince, je souhaitais que ma classe se charge elle-même de tout construire... Mais n'a-t-on pas le même problème pour agrandir ?
De ce que j'ai trouvé, la méthode n'en dit pas si long : http://docs.oracle.com/javase/7/docs...#toArray%28%29
Et que la classe Integer aurait-elle de particulier pour ne pas pouvoir émaner d'un Object ?
Dommage que la compatibilité ait voulue être conservée à tout prix avec des versions antérieures de Java lors de l'ajout de la programmation générique, ça bricke toutes les possibilités...

(Merci pour ta réponse ;) )
02/12/2013, 20h10
tchize_
De la même manière que tu ne peux pas faire en java
Code:

1 2 Object o = new Object(); Integer i = (Integer) o;
Tu ne peux pas faire
Code:

1 2 Object[] o = new Object[1]; Integer[] i = (Integer[]) o;
(Integer n'est qu'un exemple).

Je parlais d'aller voir les sources, pas la javadoc :)
03/12/2013, 09h31
thelvin

Oui enfin, ArrayList n'est pas magique. Elle fait bel et bien :

Code:

T[] array = (T[])new Object[size];

Le truc étant que le T[] array en question est private, n'est jamais exposé à l'extérieur, et n'est donc jamais casté après sa création. Ce qui évite le problème.

Rien n'empêche de faire la même chose.
Et pour le warning, ben il est normal : le compilateur signale qu'il n'est pas capable de vérifier la cohérence des types, et c'est la vérité. C'est le programmeur qui doit s'assurer qu'il ne fait pas de connerie, et notamment qu'il n'expose pas le tableau ainsi créé.
Si on est sûr de soi, pour enlever le warning, il y a l'annotation "je sais ce que je fais, je comprends l'erreur et les risques qu'elle implique, mais la conception de cette classe garantit que ces risques ne s'appliquent pas" @SuppressWarnings("unchecked"). Une description de la preuve qu'il n'y a aucune risque, sera bienvenue dans les commentaires du code.

Salut,

Citation:

Envoyé par collect

Je sais pourquoi cela est interdit (limitation de la programmation générique en Java ; T est en fait remplacé par Object),

Non au contraire c'est surtout une limitation des tableaux, qui ne garantissent pas un code typesafe (au contraire même).

Avec des tableaux tu peux très bien écrire un code comme celui-ci sans avoir aucun problème à la compilation :
Code:

1 2 3 T[] typedArray = ... Object[] objectArray = typedArray; // OK objectArray[0] = "Hello"; // ClassCastException
Mais tu risques d'obtenir une exception à l'exécution selon le type réel de T...

Tout cela à cause de l'héritage un peu trompeur des tableau (String[] hérite de Object[], etc.)
D'ailleurs ceci est également vrai avant Java 5 et les Generics...

Or l'objectif premier des Generics est d'empêcher les exceptions à l’exécution.
Mais c'est impossible de faire cela avec des tableaux, donc la création de tableau Generics est bloqué pour éviter la confusion (croire que c'est typesage alors que cela ne l'est pas)

Avec les Generics, tu n'a pas ce genre de problème, puis qu'il n'y a pas d'héritage des paramétrages.
Tu auras forcément une erreur à la compilation :
Code:

1 2 List<T> typedList = ... List<Object> objectList = typedList; // COMPILE ERROR
Au lieu de cela on peut utiliser la covariance/contravariance, mais ici aussi cela bloque les utilisations incorrects :
Code:

1 2 3 List<T> typedList = Arrays.asList(a); List<?> objectList = typedList; // OK objectList.add("Hello"); // COMPILE ERROR
Bref :

tableau Java :arrow: code non-typesafe
collections Generics :arrow: code typesafe

Citation:

Envoyé par collect

Mais ce n'est pas très propre et il reste un panneau attention à la compilation.

Si tu veux vraiment utiliser un tableau tu devras faire avec ce warning, quitte à utiliser une annotation @SuppressWarning pour dire au compilateur que tu prends en charge la responsabilité du typeage de ce code.

Par contre je te conseillerais plutôt de déclarer le tableau en Object, et d'utiliser deux méthodes get/set pour accéder à ses éléments, par exemple :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 class Plan<T> { public Plan(int yTaille, int xTaille) { plan = new Object[yTaille][xTaille]; } @SuppressWarnings("unchecked") public T get(int y, int x) { return (T)plan[y][x]; } public void set(int y, int x, T value) { plan[y][x] = value; } private Object[][] plan; }
a++

Citation:

Envoyé par thelvin

Le truc étant que le T[] array en question est private, n'est jamais exposé à l'extérieur, et n'est donc jamais casté après sa création. Ce qui évite le problème.

C'est pour ça que je parlais de la méthode toArray qui retourn un T[], où là t'es bien obligé que le type sois correct, pas comme la variable privée qui elle absue du language dans tous les sens :)
Code:

1 2 3 4 5 6 7 8 9 10 @SuppressWarnings("unchecked") public <T> T[] More ...toArray(T[] a) { if (a.length < size) // Make a new array of a's runtime type, but my contents: return (T[]) Arrays.copyOf(elementData, size, a.getClass()); System.arraycopy(elementData, 0, a, 0, size); if (a.length > size) a[size] = null; return a; }
Tu notera que le seule moyen d'instancier un T[] correct, c'est d'avoir déjà un tableau, de faire un getClass() dessus et de passer par Arrays.copyOf dont l'implétentation utilise joyeusement le reflection :)

03/12/2013, 20h40
collect

Merci à tous pour votre aide.

J'ai résolu une des erreurs d'exécution car j'utilisais le toArray de Vector, et je passe maintenant en paramètre un tableau de la bonne taille et du bon type.

Et la méthode d'adiGuba fonctionne très bien.

Juste le petit regret que les développeurs du Java ne lui donnent pas de la vraie programmation générique...
03/12/2013, 21h08
adiGuba
Citation:

Envoyé par collect

Juste le petit regret que les développeurs du Java ne lui donnent pas de la vraie programmation générique...

Comme je l'ai dit le problème ne vient pas des Generics mais des tableaux Java.

Le "problème" existe aussi avec du code qui n'utilise pas les Generics :
Code:

1 2 3 String[] stringArray = new String[10]; Object[] objectArray = stringArray; objectArray[0] = new Date(); // ClassCastException
S'il faudrait revoir quelque chose, ce serait plutôt la gestion des tableaux Java :
- Leur "héritage" particulier qui empêche d'avoir du code typesafe.
- L'impossibilité d'avoir des tableaux immutables.
- L'impossibilité de les redimensionner (sans avoir à recréer un nouveau tableau)
Les "limitations" des Generics sont bien moins problématique en pratique...

a++
03/12/2013, 21h29
collect
Oui, c'est vrai qu'ici, le problème vient surtout des tableaux, mais le mauvais générique pose aussi parfois problème (CF http://sucre.syntaxique.fr/doku.php?id=java).
Citation:
Envoyé par adiGuba

L'impossibilité d'avoir des tableaux immutables.
"final" ?
Citation:
Envoyé par adiGuba

L'impossibilité de les redimensionner (sans avoir à recréer un nouveau tableau)
Personnellement, cela me semble logique que l'on doive passer par une classe spécialisée pour cela, telle Vector, puisque cela peut se gérer de différentes manières selon les besoins...
03/12/2013, 21h42
adiGuba
Citation:

Envoyé par collect

Oui, c'est vrai qu'ici, le problème vient surtout des tableaux, mais le mauvais générique pose aussi parfois problème (CF http://sucre.syntaxique.fr/doku.php?id=java).

Il n'est pas question de Generics dans le lien que tu cites.
Au contraire la section "typage faible" fait référence à des méthodes qui utilise des Objects (pour des raisons historique), et non pas des types paramétrés Generics...

Citation:

Envoyé par collect

"final" ?

Non justement !
Le mot-clef final empêche juste d'affecter un nouveau tableau, mais cela n'empêche pas de modifier les différentes valeurs...

Citation:

Envoyé par collect

Personnellement, cela me semble logique que l'on doive passer par une classe spécialisée pour cela, telle Vector, puisque cela peut se gérer de différentes manières selon les besoins...

Hum. ArrayList plutôt parce que Vector est une antiquité.

Dès lors que tu utilises une ArrayList et via les Generics tous les problèmes des tableaux sont oubliés.
- Il n'y a pas d'héritage farfelu (une List<String> n'étend pas de List<Object>) mais on peut utiliser la variance pour écrire du code plus générique.
- On peut très bien créer une instance immuable via Collections.unmodifiableList()
- Et bien sûr on peut redimensionner plus facilement (même si en interne cela utilisera toujours un tableau).
a++
03/12/2013, 21h53
collect
Il me semble que la partie historique ne bricke pas seulement les classes préétablies, mais bloque également toute nouvelle possibilité. Lors de l'introduction de la généricité, les développeurs ont voulu laisser le langage compatible avec les anciennes versions, d'où le fait que le code générique n'est rien d'autre que remplacer "T" par "Object" (si on oublie les avertissements à la compilation).
Citation:
Mais Java est capable de bien pire que ça :

Code:

1 2 3 ArrayList<Short> foo = new ArrayList<Short>(); foo.add(12); // ok... foo.contains(12); // renvoie false !
Cette partie ne me paraît pas intéressante, il est évident que deux objets de références différentes, même s'ils contiennent la même chose, sont différents ? Sauf erreur de ma part.

Citation:

Envoyé par adiGuba

Non justement !
Le mot-clef final empêche juste d'affecter un nouveau tableau, mais cela n'empêche pas de modifier les différentes valeurs...

En effet. Ils auraient pu choisir de procéder ainsi :
Code:

1 2 3 final int[] t; // tableau à termes finaux int final[] t; // tableau à référence finale final int final[] t; // tableau à référence et termes finaux
Enfin bon, ne nous appesantissons pas là-dessus. :D
04/12/2013, 00h44
thelvin
Citation:

Envoyé par collect

Il me semble que la partie historique ne bricke pas seulement les classes préétablies, mais bloque également toute nouvelle possibilité. Lors de l'introduction de la généricité, les développeurs ont voulu laisser le langage compatible avec les anciennes versions, d'où le fait que le code générique n'est rien d'autre que remplacer "T" par "Object" (si on oublie les avertissements à la compilation).

C'est pas clair ton histoire, tu mélanges plusieurs choses.
- Pour garder la compatibilité avec le code existant, les classes génériques n'obligent pas d'utiliser leur généricité. Ce qui fait des warning et a pour effet de remplacer le type générique par Object (ou du moins le type le plus ascendant autorisé.)

- Pour garder la compatibilité avec les fonctionnalités existantes, l'égalité entre objets définie avec equals() autorise que des objets de classes arbitrairement éparses puissent être considérées égales. Cette propriété étant utilisée pour la recherche dans des collections, elle a dû être gardée et tout ce qui est recherche d'objet présent se fait avec paramètre Object.
Pour éviter ça, il aurait fallu créer de nouvelles relations d'égalité imposant que la classe comparant soit ascendante de l'autre, et de nouvelles collections qui s'en servent. Pas impossible mais lourd pour peu de gains.

Citation:

Envoyé par collect

Cette partie ne me paraît pas intéressante, il est évident que deux objets de références différentes, même s'ils contiennent la même chose, sont différents ? Sauf erreur de ma part.

Plus exactement cet exemple est faux. Java n'est pas capable de faire ça. Ce bout de code ne compile pas.

Par contre ce bout de code-ci compile :
Code:

1 2 3 4 ArrayList<Short> foo = new ArrayList<Short>(); Short s = 12; foo.add(s); // ok... foo.contains(12); // renvoie false !
et c'est presque la même chose.

Tu te dis que c'est normal, mais non. Que se passe-t-il si on utilise une ArrayList<Integer> au lieu de <Short> ?
Le problème illustré dans cet exemple, c'est qu'une Collection<T> utilise le paramètre T à l'ajout (pour assurer que les objets contenus dans la Collection sont bien du type paramétré,) mais Object au test d'appartenance (pour respecter le mécanisme historique de relation d'égalité.)

Ce qui signifie que si le paramètre <T> est fixé à Short, le add() prendra comme paramètre add(Short e), qu'on peut lui fournir avec Short s = 12;. Alors que le contains() aura comme paramètre contains(Object o), et qu'on peut appeler dessus contains(12), ce qui créera une instance d'Integer, et non pas de Short, qui vaut 12.
Short et Integer ne sont jamais equals() et c'est la raison pour laquelle add() et contains() ne s'y retrouvent pas en leur passant chacun un nombre qui vaut 12.
Si le type paramétré était Integer, les deux instances créées seraient Integer, elles seraient equals() et par définition, contains() renverrait true.

C'est effectivement un problème de typage assez faible, où s'emmêlent le contains() qui n'utilise pas les génériques, et l'auto-inbox qui convertit implicitement les types de base en leur équivalent objet.

Ça peut être déroutant, mais rarement en pratique. Par exemple l'intérêt d'une liste de Short ne va pas loin, sauf si l'idée est de contraindre la plage de valeurs possibles des nombres, et non pas d'occuper moins de mémoire.
04/12/2013, 09h08
adiGuba
Citation:

Envoyé par collect

Il me semble que la partie historique ne bricke pas seulement les classes préétablies, mais bloque également toute nouvelle possibilité. Lors de l'introduction de la généricité, les développeurs ont voulu laisser le langage compatible avec les anciennes versions, d'où le fait que le code générique n'est rien d'autre que remplacer "T" par "Object" (si on oublie les avertissements à la compilation).

:arrow: Comme l'indique thelvin, cela ne concerne pas les Generics puisque la méthode contains(Object) utilise un type Object et non pas un type T !

Certaines méthodes des Collections, basé sur l’égalité (comme contains()), n'utilisent pas les Generics car il n'y a pas forcément besoin d'avoir un typage fort pour cela.
Citation:
Envoyé par collect

En effet. Ils auraient pu choisir de procéder ainsi :

Code:

1 2 3 final int[] t; // tableau à termes finaux int final[] t; // tableau à référence finale final int final[] t; // tableau à référence et termes finaux
En fait il serait plus simple de "supprimer" les tableaux Java du langage, purement et simplement.
Le tout en les remplaçant par une classe Array<T> qui proposerait les mêmes fonctionnalité via un vrai objet, bien plus flexible via les Generics et la covariance/contravariance en remplacement de l'héritage "particulier" des tableaux...

Plus globalement il est de "bon ton" de critiquer les Generics de Java à cause du type-erasure, même si les problèmes que cela pose sont minime et facilement contournable.
Mais en pratique le truc est quand même vachement bien foutu et bien pensé !

a++
14/12/2013, 21h38
collect

Oui, c'est vrai, mais c'est toujours un inconvénient, de devoir s'adapter aux particularités de chaque langage, et d'avoir parfois des résultats non escomptés, qui seraient logiquement absurdes. Cela peut compliquer le debug.

Merci pour votre aide en tout cas !
15/12/2013, 07h55
adiGuba

Citation:

Envoyé par collect

Oui, c'est vrai, mais c'est toujours un inconvénient, de devoir s'adapter aux particularités de chaque langage, et d'avoir parfois des résultats non escomptés, qui seraient logiquement absurdes. Cela peut compliquer le debug.

Qu'est-ce qui est "logiquement absurdes" ?

a++