Discussion :

[ikeas]

Bonjour,

je rencontre un petit probleme avec java
notament avec les fonctions static et les generics
voila ce que j'aimerais avoir

Code :

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

1
2
3
4
5
6
7
8
9
10
public class Plugs<T> {
 
	public Plugs() {
	}
 
	public static <T> ArrayList<T> discover(String path) {
		System.out.println("Discover dans plus<T>");
		return null;
	}
}

une classe qui permet par le biais de l'introspection de decouvrir toutes les classes implementant une type defini par T

si la définition de la classe ci dessus passe a la compilation, pour l'utilisation .... ca passe pas ....

Code :

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

ArrayList<IBase> list =	Plugs<IBase>.discover("");

me genere une erreur
Multiple markers at this line
- IBase cannot be resolved to a variable
- The method discover(String) is undefined for the
type Main
- Syntax error on token ".", delete this token
- Plugs cannot be resolved to a variable

si je fais

Code :

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

 ArrayList<IBase> list0 = Plugs.discover("");

ca passe mais je me demande alors comment il sait ce qu'est T ....

si vous avez une idée
pour info je viens du c# et j'aimerais faire une factory (donc plutot une classe static)
avec evidement seulement des membres static

merci

[thelvin]

si la définition de la classe ci dessus passe a la compilation, pour l'utilisation .... ca passe pas ....

Comme le générique s'applique à la méthode et non à la classe, la syntaxe correcte est :

Code :

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

ArrayList<IBase> list =	Plugs.<IBase>discover("");

Mais ce n'est pas nécessaire. La syntaxe ArrayList<IBase> list = Plugs.discover(""); est équivalente.

ca passe mais je me demande alors comment il sait ce qu'est T ....

Il ne sait pas. En Java les génériques n'existent qu'au compile-time, pas au runtime. Le compilateur sait que <T> est <IBase> parce que la méthode renvoie ArrayList<T> et que tu affectes le résultat à une ArrayList<IBase>. Pas compliqué d'inférer ce que tu veux que <T> représente.

... Mais la méthode sera incapable de rechercher quoi que ce soit basé sur ce paramètre générique, car ce paramètre n'existe pas au runtime. Il te faudrait quelque chose du genre :

Code :

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

public static <T> ArrayList<T> discover(Class<T> type, String path)

que tu peux appeler comme ça :

Code :

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

ArrayList<IBase> list0 = Plugs.discover(IBase.class, "");

Deux remarques :
- Au départ Java ne propose pas de moyen clair de rechercher toutes les implémentations d'une classe ou interface. Il existe des bibliothèques tierces qui font cette recherche, mais tu en auras besoin.
- Il serait plus élégant de manipuler des List plutôt que des ArrayList. ArrayList ce sera juste au moment de faire le new.

[adiGuba]

Salut,


Je rajouterais juste que dans le cas précis la classe Plugs n'a pas à être Generics.
C'est seulement sa méthode static qui doit l'être :

Code :

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

1
2
3
4
5
public class Plug {
	public static <T> ArrayList<T> discover(String path) {
		...
	}
}

a++

[ikeas]

merci je vais tenter cela

j'ai un problème sous jacent c'est que j'ai besoin de récupérer le nom de mon T
par exemple si j'ai Plug<IBase> je devrais avoir sample.interfaces.IBase

je suppose qu'en utilisant

Code :

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

public static <T> ArrayList<T> discover(Class<T> type, String path)

ca devrait etre simple mais moins "sexy"

y'a ti'il une possibilité pour reccuperer le nom dans

Code :

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

ArrayList<IBase> list =	Plugs.discover("");

merci en tout cas pour les infos precendantes

[adiGuba]

y'a ti'il une possibilité pour reccuperer le nom dans

Code :

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

ArrayList<IBase> list =	Plugs.discover("");

Non, il faut passer par un paramètre de type Class<T>.

Et ce n'est pas forcément moins "sexy" que le bout de code de ton premier post :

Code :

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

1
2
3
ArrayList<IBase> list =	Plugs.discover(IBase.class, "");
// VS
ArrayList<IBase> list =	Plugs<IBase>.discover("");

a++

[ikeas]

oui merci

pour moi le coté sexy viens du fait que ça me semble plus simple en c# (voir meme en c++)

[adiGuba]

pour moi le coté sexy viens du fait que ça me semble plus simple en c# (voir meme en c++)

Sauf que le C#/C++ aboutira à une duplication de code pour chaque type utilisé, alors que c'est quasi inutile dans ce cas...


a++

[ikeas]

merci en tout cas

[Gugelhupf]

Sauf que le C#/C++ aboutira à une duplication de code pour chaque type utilisé, alors que c'est quasi inutile dans ce cas...


a++

Pour une futur version de Java, ils pensent à mettre en place la reification, donc ce sera plus ou moins le même principe qu'en C# (lien article). Le type erasure partira aux oubliettes.
Enfin je ne pense pas que ce sera de sitôt, vu comment ils ont pollués le package function avec les interfaces XXXFunction.

[adiGuba]

Pour une futur version de Java, ils pensent à mettre en place la reification, donc ce sera plus ou moins le même principe qu'en C# (lien article). Le type erasure partira aux oubliettes.
Enfin je ne pense pas que ce sera de sitôt, vu comment ils ont pollués le package function avec les interfaces XXXFunction.

Le problème vient plus des types primitifs que des Generics.
Mais c'est surtout l'arrivée des types "value" qui va poser problème en l'état.


Mais ce n'est pas dit que les type-erasures partent aux oubliettes...
Dans le projet "valhalla" ils parlent plutôt de specialization, et si j'ai bien compris cela consiste en une réification mais seulement pour les types primitifs et les types "value".
Plus de détail ici : http://cr.openjdk.java.net/~briangoe...alization.html


Pour les références, une réification n'apporterait pas grand chose...


a++

[Gugelhupf]

Je dois avouer que je n'ai pas tout compris, mais si tel est le cas, ce serait dommage car le mécanisme de type erasure impose beaucoup de contrainte par rapport à la reification lors du développement, comme l'instanciation d'objet générique en rajoutant un paramètre de type Class<T>, caster les tableaux de génériques, le problème de surcharge de méthode...

[adiGuba]

Je dois avouer que je n'ai pas tout compris, mais si tel est le cas, ce serait dommage car le mécanisme de type erasure impose beaucoup de contrainte par rapport à la reification lors du développement, comme l'instanciation d'objet générique en rajoutant un paramètre de type Class<T>, caster les tableaux de génériques, le problème de surcharge de méthode...

La réification n'est pas forcément utile pour cela.
Le paramètre Class<T> pourrait être passé automatiquement via du sucre syntaxique, et permettre certaines syntaxes plus facilement dans le code (comme new T[] ou T.class).
Toutefois cela ne change pas grand chose pour new T() qui sera toujours autant problématique (que faire si T ne comporte pas de constructeur ? Si c'est une interface ? Une classe abstraite ? Une enum/annotation ? Un type primitif ?).

Il y aurait juste un petit coût mémoire supplémentaire (lié à la référence du Class<T>) qui doit sûrement être une des raisons que cela n'ait pas été implémenté.



Pour le cast des tableaux génériques tu parles bien de ceci :

Code :

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

List<String>[] listArray = (List<String>[]) new List[10];

C'est particulièrement crade car les tableaux sont unsafe de nature.
La réification des Generics ne ferait que décaler le problème... et c'est pas dit que le warning disparaissent car ce genre de code serait toujours aussi unsafe !



Pour la surcharge des méthodes, c'est presque un autre débat aussi.
Certains considère la surcharge de méthode comme dangereuse car cela complexifie la résolution de méthode et entraine plusieurs limitations (par exemple un vrai mécanisme de paramètre optionnel est impossible à mettre en place à cause de cela).
Mais encore une fois je pense qu'il est techniquement possible de faire cela sans forcément passer par de la réification, surtout que les signatures de méthodes conservent bien le paramétrage Generics au runtime...




A coté de cela l'implémentation des Generics a permis :

• Une rétrocompatibilité du code, permettant de mixer des APIs utilisant les Generics avec d'autres qui ne les utilisant pas (et c'était essentiel au moment de la sortie de Java 5)
• Une covariance/contravariance complète, et non pas limité à un type comme c'est le cas dans C# 4.0, ni restreinte au concepteur de la classe.
• Pas d'explosion du nombres de type chargé en mémoire (en analysant vite-fait les sources du JDK8, je retrouve 200 List<T> différents. Une réification impliquerait de charger 200 classes supplémentaire en mémoire).

Bref c'est loin d'être la "mauvaise" solution comme bon nombre aime le penser...

a++

[ikeas]

c'est marrant par ce qu'en c# c'est quand même super simple
ce que je comprend pas c'est que la notion de type ne soit pas aussi simple que justement en c#

pour la culture perso http://msdn.microsoft.com/fr-fr/library/512aeb7t.aspx

enfin plus globalement je me suis amusé en java, y'a bcp de choses qui manquent dans le langage ... c dommage

[thelvin]

c'est marrant par ce qu'en c# c'est quand même super simple

Au prix tout de même de la duplication du code runtime. Après, que ce soit pas forcément un problème, je veux bien le croire. Ça me dérangeait pas quand je faisais du C++

ce que je comprend pas c'est que la notion de type ne soit pas aussi simple que justement en c#

Pas besoin d'aller le chercher loin, pourtant. Java existe depuis bien avant que les génériques soient à la mode, et les ajouter après coup à la même mode que C++/C# aurait été désastreux pour l'existant.
Je n'ai pas assez de connaissance sur C# pour savoir pourquoi il n'a pas eu le problème, mais dans le grand ordre des choses, exister depuis moins longtemps et avoir commencé à exister dans un contexte plus moderne, ça apporte fatalement des avantages. Infiniment moins d'existant à casser, une introspection plus flexible...

Après, la covariance étant quand même bien pratique, il est pas impossible que ça soit aussi une préférence de conception. Mais j'ai des doutes.

[adiGuba]

c'est marrant par ce qu'en c# c'est quand même super simple
ce que je comprend pas c'est que la notion de type ne soit pas aussi simple que justement en c#

Il y a une historique bien différente derrière...

En C# il y a duplication du type, et donc une utilisation mémoire potentiellement plus importante.
Il y a également eu une incompatibilité avec tous les codes et librairies existante selon l'API de Collections qu'on utilise (System.Collections ou System.Collections.Generic)

Sans compter la covariance/contravariance assez tardive (C# 4.0 si je ne me trompe pas).
Il était par exemple impossible d'écrire quelque chose comme cela :

Code :

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

1
2
3
	public static void print(List<?> list) {
		System.out.println("Il y a " + list.size() + " éléments dans la liste.");
	}

Il fallait dupliquer la méthode manuellement pour chaque type de List que tu utilisais !
Vachement sexy en effet


Les Generics de Java ont certes quelques défauts via à vis de ceux de C#... mais c'est également le cas dans l'autre sens.

pour la culture perso http://msdn.microsoft.com/fr-fr/library/512aeb7t.aspx

enfin plus globalement je me suis amusé en java, y'a bcp de choses qui manquent dans le langage ... c dommage

Oui si tu cherches à t'amuser C# est peut-être plus adapté : le langage a eu une boulimie de fonctionnalité !


L'évolution de Java est plus lente et (avis perso) plus réfléchis.


a++

[ikeas]

je viens du monde c# en fait
je me suis amusé en java y'a fort longtemps
et plus recement sur android ...

ca reste sympa quand meme