Discussion :

[lvr]

Bonjour,

J'ai une méthode

Code :

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

1
2
3
private itMessageDisplayer<T> createDisplayer(Class<? extends itMessageDisplayer<T>> DisplayerClass, 
	T message)
Qui doit créer un un objet de type Class<? extends itMessageDisplayer<T>>

Cet objet a un constructeur ayant cette forme:

Code :

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

1
2
public static class DefaultNonEditableDisplayer<M> extends JLabel implements itMessageDisplayer<M> {
	public DefaultNonEditableDisplayer(clComboMessage<M> combo, M message) {

Donc j'écris:

Code :

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

1
2
3
4
5
6
private itMessageDisplayer<T> createDisplayer(Class<? extends itMessageDisplayer<T>> DisplayerClass, T message) throws ...
	// On crée le Displayer
	itMessageDisplayer<T> d = null;
	java.lang.reflect.Constructor<? extends itMessageDisplayer<T>> c =
		DisplayerClass.getConstructor(clComboMessage.class, T.class);
	d = c.newInstance((clComboMessage<T>)this, message);

Le problème c'est le T.class. Ca ne marche pas.
Est-ce possible d'écrire quelque chose de ce genre ?
J'ai lu dans un autre forum que la suggestion était de remplacer le T.class par une classe plus concrète. Mais pour T, il n'y a aucune restriction sur ce qu'il peut être, donc je devrais remplacer T.class par

Code :

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

1
2
java.lang.reflect.Constructor<? extends itMessageDisplayer<T>> c = 
	DisplayerClass.getConstructor(clComboMessage.class, Object.class);

J'ai aussi pensé à écrire à la place de T.class

Code :

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

1
2
java.lang.reflect.Constructor<? extends itMessageDisplayer<T>> c =
	DisplayerClass.getConstructor(clComboMessage.class, message.getClass());

Mais si message est d'une sous-classe de T, est-ce que mon constructeur va être trouvé ?

Donc me voilà encore une nouvelle fois un peu perdu avec les génériques

Merci pour vos suggestions de solutions,

Laurent

[gifffftane]

De ce que je comprends des génériques, cela devrait fonctionner avec Object.class... ce n'est pas le cas ?...

Tu pourras trouver des considérations sur ces questions à Java Generics FAQs / Reflection.

[lvr]

De ce que je comprends des génériques, cela devrait fonctionner avec Object.class... ce n'est pas le cas ?...

J'ai tellement d'erreur que je ne peux pas encore tester J'ai mis Object.class. Je verrai ce que ça donne dès que je peux compiler.
Merci.

[lvr]

Bon je n'arrive toujours pas à compiler. Problème suivant du même ordre:

J'ai une classe qui permet d'associer un type de classe et une instance de cette classe:

Code :

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

1
2
3
4
private static class DisplayerGetter<M> {
   public DisplayerGetter(Class<? extends itMessageDisplayer<M>> displayerclass) {
      this(displayerclass, null);
   }

Je voudrais créer une nouvelle instance de cette classe avec ceci

Code :

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

1
2
3
public class DisplayerMidi<T> extends clComboMessage.DefaultNonEditableDisplayer<T> {... }
 
public static class DefaultNonEditableDisplayer<M> extends JLabel implements itMessageDisplayer<M> { ... }

Donc ça colle...

Je voudrais le faire comme ceci

Code :

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

1
2
DisplayerGetter<T> arr;
arr = new DisplayerGetter<T>(DisplayerMidi<T>.class);

Mais "DisplayerMidi<T>.class" n'est pas accepté.
J'ai donc trouvé deux alternatives:

Code :

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

1
2
DisplayerGetter<T> arr;
arr = new DisplayerGetter<T>(DisplayerMidi.class);

qui donne comme erreurs:
- cannot find symbol; symbol : constructor DisplayerGetter(java.lang.Class<DisplayerMidi>), location: class DisplayerGetter<T> at line 51, column 15
- internal error; cannot instantiate DisplayerGetter.<init> at DisplayerGetter<T> to () at line 51, column 15


ou

Code :

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

1
2
DisplayerGetter<T> arr;
arr = new DisplayerGetter(DisplayerMidi.class);

qui donne comme avertissements:
- [unchecked] unchecked call to DisplayerGetter(java.lang.Class<? extends itMessageDisplayer<M>>) as a member of the raw type DisplayerGetter at line 51, column 15
-[unchecked] unchecked conversion; found : DisplayerGetter, required: DisplayerGetter<T> at line 51, column 15

Ne serait-il donc pas possible d'éviter le warning ?
Je viens de lire une grosse partie de la FAQ, mais je n'ai pas trouvé la réponse.

Merci.

[gifffftane]

Tout cela me donne un peu mal à la tête... pourquoi fais-tu toussa ?

J'ai l'impression que tu voudrais donner un niveau de généricité supérieur au générique. Mais tu compliques les écritures, et du coup tu es paumé. Trop de généricité tue la généricité. Par ex. quand tu déclares une variable telle que DisplayerGetter<T> arr;, il faudrait que tu aies déclaré T quelque part, or, je vois private static class DisplayerGetter<M>... M n'étant pas T, cela me donne à penser que T est une erreur... Bref, il faudrait décompliquer un peu, je pense.

[adiGuba]

Salut,



Tu ne peux pas éviter ces warnings car tu mélanges deux mondes :

• Les Generics qui t'assurent une vérification des types à la compilation, et donc un code typesafe à l'exécution.
• La reflection qui te permet de manipuler les types à l'exécution, et donc potentiellement source d'erreur de type pendant l'exécution. D'autant plus que les types paramétrées n'existe plus à l'exécution...

Tous les warnings/erreurs généré par les Generics indiquent un problème potentiel... et tu as un grand nombre de cas lorsque tu mélanges Generics et reflection...

Donc si tu es vraiment sûr de toi et de ton code tu peux utiliser @SuppressWarnings pour "cacher" ce message et prendre à ton compte la vérification des types et de la cohérence de l'ensemble...


Maintenant j'ai du mal à comprendre l'objectif de tout cela : que veux-tu faire exactement ?

a++

[sethys]

Maintenant j'ai du mal à comprendre l'objectif de tout cela : que veux-tu faire exactement ?

+1, Ce code doit pas être facile à maintenir même si l'idée semble intéressante, ça fait beaucoup d'enchainements de Generic

[lvr]

Merci pour vos réponses.

Pour synthétiser ce que je fais, c'est une extension de JComboBox qui permet de sélectionner, modifier et créer des objets implémentant une interface <T>. J'ai quatre ou cinq catégories d'objets suivant T. Chaque objet est modifiable et créable via un "Displayer" spécifique. Ce displayer implémente l'interface itMessageDisplayer<T>.
Comme je voulais faire des économies de mémoire, je ne crée les displayer que lorsqu'on en a besoin.
Donc je fais une map qui indique: tel type d'objet requiert tel type de displayer et en voilà une instance à utiliser, où l'instance est nulle tant qu'on n'en a pas eu besoin.
D'où la Map qui dit
Si tu dois afficher un message x voici un DisplayerGetter qui te donner un displayer adhoc.
et l'entité DisplayerGetter qui dit
lorsque tu as besoin d'un DisplayerMidi<T> (Class<? extends itMessageDisplayer<M>>), en voici une instance à utiliser (itMessageDisplayer<M>).

Comprenant de mieux en mieux les génériques, je suis arrivé à réduire mes warning à 2, pour toute cette classe, et je ne pense pas qu'il soit faisable de faire mieux.

Par contre ce que je ne comprend pas c'est:
1) S'il n'est pas possible d'écrire "DisplayerMidi<T>.class" pourquoi est-ce que le compilateur se plaint si j'écris "DisplayerMidi.class" ?
Surtout que si j'écris "(DisplayerMidi<T>) mondisplayer.getClass()" ce warning disparaît (mais un autre apparaît).

2) Pourquoi, est-ce que lorsque j'ai un objet qui instancie "DisplayerMidi<T>", le getClass() sur cet objet retourne "Class<DisplayerMidi>" et pas "Class<DisplayerMidi<T>>" ?

Tout n'est pas encore clair pour moi

Laurent

[gifffftane]

Pour synthétiser ce que je fais, c'est une extension de JComboBox qui permet de sélectionner, modifier et créer des objets implémentant une interface <T>.

Mmmmmm.... cela commence mal, cela ne veut rien dire : tu peux implémenter une interface T, tu ne peux pas implémenter une interface <T>.

Il est très important, avec les génériques, de bien faire la différence avec quelque chose dont on peut hériter ou se référer, et quelque chose que l'on va conserver ; un générique exprime quelque chose que l'on va conserver. Ce quelque chose est un nom de classe ou interface. Un générique exprime que l'on va utiliser ce nom en toute rigueur. C'est tout.

Comme tu as l'air de t'intéresser aux génériques, je présume que tu voudrais utiliser n'importe quelle objet comme rang d'une JComboBox, en te donnant un peu de rigueur au niveau des déclarations.

J'ai quatre ou
cinq catégories d'objets suivant T. Chaque objet est modifiable et créable via un "Displayer" spécifique. Ce displayer implémente l'interface itMessageDisplayer<T>.
Comme je voulais faire des économies de mémoire, je ne crée les displayer que lorsqu'on en a besoin.

Les génériques ne sont pas faciles à utiliser pour ce qui concerne la création d'objets. En effet pour se faire on a besoin à un moment ou un autre du nom exact de la classe.

C'est donc une bonne chose que d'avoir un Displayer spécifique par catégorie ; cela te permet, je présume, de disposer du nom exact de la classe ; mais je ne comprends pas pourquoi tu lui fais implémenter une interface itMessageDisplayer<T> ? Quel est l'objectif ici ?

Pour les économies de mémoire, c'est utile pour les JTree ou les JTable, mais pour un JComboBox ? les tiens sont si gros ?

Donc je fais une map qui indique: tel type d'objet requiert tel type de displayer et en voilà une instance à utiliser, où l'instance est nulle tant qu'on n'en a pas eu besoin.
D'où la Map qui dit
Si tu dois afficher un message x voici un DisplayerGetter qui te donner un displayer adhoc.
et l'entité DisplayerGetter qui dit
lorsque tu as besoin d'un DisplayerMidi<T> (Class<? extends itMessageDisplayer<M>>), en voici une instance à utiliser (itMessageDisplayer<M>).

Pourquoi ne te donnes-tu pas une classe par catégorie ? Cela simplifierait drastiquement tout cela, non ?

Et si ces catégories expriment un classement utilisateur, et que tu hésites donc à en faire des classes java trop figées, alors, non seulement tu n'as probablement pas besoin de les distinguer lors de la création de l'objet, mais tu ne pourras pas les exprimer à l'aide de génériques, puisque avec les génériques tu ne peux exprimer que des classes ou interfaces.

Pour les cas particuliers de warnings, il faudrait que tu nous donnes ou redonnes le code exact sur PAS PLUS DE 5 LIGNES, et non pas 36 sources !

[lvr]

Envoyé par lvr Voir le message
Pour synthétiser ce que je fais, c'est une extension de JComboBox qui permet de sélectionner, modifier et créer des objets implémentant une interface <T>.

Mmmmmm.... cela commence mal, cela ne veut rien dire : tu peux implémenter une interface T, tu ne peux pas implémenter une interface <T>.

Ce que je voulais dire c'est que les valeurs que je donne à T sont toujours des interfaces, jamais des classes d'objets.
Pour le reste, c'est un peu hors sujet de tout décrire.
Je clos ce sujet.... mais je risque de revenir avec le problème suivant.
Encore merci pour vos aides....