Génériques. Connaitre le type supporté

Bonjour,

Je me suis crée un objet générique :

Code:

---

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

public class Group<T> implements Comparable<Group<T>>, Serializable {   /** Serial version UID */ private static final long serialVersionUID = 741587360128392267L;   T holded;   private String name; private String description; private List<T> items;   // Constructeurs et accesseurs ... }

---

Mais je voudrais pouvoir donner à mon attribut 'holded' la classe de l'objet supporte (le type de T). Je voudrais faire cela sans avoir à le recevoir dans le constructeur.
Est-ce possible ?

Merci

Je n'ai pas très bien compris ta question.
Tu veux restreindre le type T ?
Tu peux obliger le type T à dériver d'une classe, lors de la déclaration.

Bonjour,

Code:

---

1 2 3

Class<T> type = (Class<T>) ((ParameterizedType) getClass() .getGenericSuperclass()).getActualTypeArguments()[0];

---

@+

Super grand merci djo.mos.

Sauf que j'ai une ClassCastException .. :'(

Citation:

---

java.lang.ClassCastException: java.lang.Class cannot be cast to java.lang.reflect.ParameterizedType

---

Surement un problème de parenthèses. Tu as essayé

Code:

---

(ParameterizedType)( getClass().getGenericSuperclass() )

---

Salut,


Le ClassCastException est normal... puisque rien ne garantit que le retour soit un ParameterizedType...


Que veux-tu faire exactement ? Obtenir le type paramétré ? :arrow: ce n'est pas possible !


Un peu de lecture : Les Generics ne sont pas des Templates comme les autres !


a++

Oui, j'en étais arrivé à la même conclusion pour la ClassCastException..

Ca m'embête bien de devoir passer également la classe au constructeur, ça fais "moins pro" et double un peu le fonctionnement puisque je dois préciser le type dans les < .. > et au constructeur.
Donc un petit bémol aux génériques.


Edit : Note qui si je voulais je pourrais tenter un truc du style :

Code:

---

1 2 3 4 5 6 7

public void addItem(T item) { if ( holded==null ) { holded = (Class<T>) item.getClass(); } items.add(item); }

---

Mais ça ne m'arrange pas car tant que je n'ai pas ajouté d'item je ne sais pas ce qu'il contient..

Ps : Merci pour ton article. Je ne l'avais pas lu parce que pas trouvé..

Peur-être devrais-tu revoir la façon de penser ta conception ?
Dans ton exemple (je ne sais pas si ta question initiale portait dessus ou si c'est un exemple rapide pour nous faire comprendre ta problématique) la méthode "addItem" n'a aucune raison conceptuelle d'ajouter un élément si le paramètre est null.
Pour quelle raison veux-tu instancier "dynamiquement" cet objet ?

Non, c'est un véritable objet que je serais amené à utiliser.

EN effet, 'addItem()' ne dois pas ajouter un objet null mais je ne vois pas en quoi cela change mon problème.
Je ne connaitrais toujours pas le type d'objet supporté avant d'en avoir ajouté un (non null)

C'est dangereux d'utiliser cela comme ça :

Mettons que tu aies B extends C.

Tu t'attends à avoir une classe B ou C car ce sont celles que tu as définies. Mais une fois que tu as choisi C, tu ne pourras plus accepter de B, car leurs classes sont différentes.

@Blaise: :oops:, j'y comprends plus rien moi non plus: le bout de code que je t'ai donné marche parfaitement dans un contexte web (je l'utilise dans mes DAOs JPA) mais donne la ClassCastException quand je le testes dans un contexte java ordinaire :cfou:

Je vais approfondir ça dès que je respires un peu au boulot ;)

Citation:

---

Envoyé par dingoth

Tu t'attends à avoir une classe B ou C car ce sont celles que tu as définies. Mais une fois que tu as choisi C, tu ne pourras plus accepter de B, car leurs classes sont différentes.

---

Oui bien sur mais je ne vois pas ou est le problème. Si ma classe Group peux contenir des objets Parent et que je décide de l'istancier pour qu'elle ne contienne que des Enfant (qui étendent Parent). Il est normal que je ne puisse plus rajouter de Parent..
Enfin, je trouve..
Edit : Ha non, désolé je n'avais pas compris. Oui en effet c'est dangereux. Mais pas dans le sens de l'ajout. Disons que je fasse ceci :

Code:

---

1 2 3 4 5 6 7

Group grp = new Group<Parent>();   Enfant e = new Enfant("Plip"); // extends Parent grp.addItem(e);   Parent p = new Parent("Plop"); grp.addItem(p);

---

Je m'attends à avoir holded (classe gérée par mon groupe) qui vaut 'Parent' mais étant donné que mon premier ajout est 'Enfant'. Je suis foutu.
Par contre je pourrais toujours ajouter un objet 'Parent'

Citation:

---

Envoyé par djo.mos

@Blaise: :oops:, j'y comprends plus rien moi non plus: le bout de code que je t'ai donné marche parfaitement dans un contexte web (je l'utilise dans mes DAOs JPA) mais donne la ClassCastException quand je le testes dans un contexte java ordinaire :cfou:

Je vais approfondir ça dès que je respires un peu au boulot ;)

---

Dans mon cas ce seras dans un projet web mais je développe et test mon DAO hors du contexte web avant.
Ce n'est pas du tout bloquant pour mon projet mais je cherche aussi une réponse au problème...
Remarque qu'après avoir lu l'article de d'adiGuba il semble logique que cela ne sois pas possible. En cherchant sur Internet, je n'ai pas trouvé de réponse directe mais une foule d'article sur les Generics, peut-être y trouverais-je une réponse. (Même si je ne trouve pas de réponse j'aurais au moins appris un tas de choses sur le sujet)

Citation:

---

Envoyé par djo.mos

@Blaise: :oops:, j'y comprends plus rien moi non plus: le bout de code que je t'ai donné marche parfaitement dans un contexte web (je l'utilise dans mes DAOs JPA) mais donne la ClassCastException quand je le testes dans un contexte java ordinaire :cfou:

---

Cela ne vient pas d'une différence de contexte mais d'une différence d'héritage.


Ici on obtient une exception car la super-class n'est pas Generics, donc getGenericSuperclass() ne retourne pas un ParameterizedType mais une simple Class...


Mais même lorsque la superclass est Generics on ne peut pas forcément obtenir cette information...

Prenons la classe generics suivante :

Code:

---

1 2 3

class MaClasseGenerics<T> {   }

---

Lorsqu'on hérite de cette classe on a deux choix :

1. Conserver les Generics, ou les spécialiser, par exemple :
   
   Code:

   ---

   1 2 3 4 5 6 7

   class MaClasseFilleGeneric<T> extends MaClasseGenerics<T> {   }   class MaClasseFilleGeneric2<T extends Number> extends MaClasseGenerics<T> {   }

   ---

   :arrow: Dans ce cas le code donné plsu haut retournera bien un ParameterizedType, mais le getActualTypeArguments() ne retournera pas une Class mais un objet Type représentant le type paramétré... qui ne te donnera principalement que le nom du type paramétré (T) et son bound-type (Object comme rien n'est précisé)
   
   
2. A l'inverse si tu fais ceci :
   
   Code:

   ---

   1 2 3

   class MaClasseStandard extends MaClasseGenerics<Double> {   }

   ---

   Alors le code donné plus haut fonctionnera parfaitement, et te renverra bien le Double, mais seulement parce qu'il s'agit d'un héritage qui spécifie "en dur" le type paramétré...

:arrow: Il faut bien se rappeler que la reflection retourne des informations globales à un type, et non pas propre à une instance. Donc grosso modo tout ce qui est retourné par la reflection doit se retrouver dans le code de la classe en question (et non pas dans le code où elle est utilisée).




Pour moi la meilleur solution serait de passer le type paramétré en paramètre du constructeur :

Code:

---

1 2 3 4 5 6 7 8 9 10

class MaClasseGeneric<T> { private final Class<T> type;   public MaClasseGeneric(Class<T> type) { if (type==null) { throw new NullPointerException(); } this.type = type; } }

---

a++

Citation:

---

Envoyé par adiGuba

Pour moi la meilleur solution serait de passer le type paramétré en paramètre du constructeur :

---

Oui il me semblait bien que c'était la seule solution. C'est surement pour cela que l'on retrouve cette pratique un peux partout. Mais j'aurais juste aimé pouvoir faire sans.. Tant pis :(.

Merci.