Discussion :

[BiM]

Bonjour,

Je cherche à faire de la réflection de méthode avec des arguments de type dérivé.

J'utilise la méthode getMethod(...) de la classe Class.

Je veux retrouver le type de retour de la méthode println() de la classe java.io.PrintStream dont l'argument est de type java.util.Comparator.

Code Java :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
Class type = java.io.PrintStream.class;
String nom = "println";
Class[] args = new Class[1];
args[0] = java.util.Comparator.class;
 
try {
	Method methode = type.getMethod(nom, args);
	type = methode.getReturnType();
} catch (SecurityException e) {
	e.printStackTrace();
} catch (NoSuchMethodException e) {
	e.printStackTrace();
}

Il devrait me retrouver la méthode PrintStream.println(Object) mais il n'en est rien, j'ai plutôt une exception... :

java.lang.NoSuchMethodException: java.io.PrintStream.println(java.util.Comparator)
at java.lang.Class.getMethod(Unknown Source)
at fr.societe.projet.MaClasse.maMethode(MaClasse.java:XXX)
at [...]

Comment remédier à ce problème sans avoir à tester toutes les méthodes héritées et implémentées ? (Surtout que ça peut devenir compliqué à partir de deux arguments)

[EDIT]
J'ai également lu ce sujet : http://www.developpez.net/forums/d77...introspection/
... qui correspond à mon problème. Cependant, j'ai une remarque sur le post #5 : A priori, un appel ambigu ne peut pas être fait en Java, une erreur de compilation est censée être retournée (à moins que ce ne soit qu'un simple avertissement ).

Bref, la question est du coup restée en suspens.
[/EDIT]

[LittleBean]

Salut,

Pas de solution simple à ma connaissance ...

Tu peux partir dans l'analyse d'héritage et implémentation, mais ça peut être complexe

sinon la méthode empirique bourrin, tu récupères celle qui s'exécute

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
	public static void main(String[] args2) {
		Class type = java.io.PrintStream.class;
		String nom = "println";
		Class[] args = new Class[1];
		args[0] = java.util.Comparator.class;
 
			Method[] methods = type.getMethods();	
			for (Method method : methods) {
			boolean ok = true;
				try {
					method.invoke(type, args);
				} catch (IllegalArgumentException e) {
					ok = false;
				} catch (IllegalAccessException e) {
					ok = false;
				} catch (InvocationTargetException e) {
					ok = false;
				}
				if (ok){
					System.out.println(method);
				}
			}
	}

[edit]
En fait ce code ne fonctionne pas invoke s'applique que des instances d'objets, on peut en récupérer avec newInstance mais ce n'est pas vraiment généralisable (Interface ... ) puis à y repenser ça ne me semble pas une bonne appproche
[/edit]
Bon le code peut être amélioré mais c'est une piste ....

Bon courage

[BiM]

OK, merci, c'est bien ce qui m'inquiétait.

Perso, j'ai fait ça en solution d'"urgence" :

Code Java :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
Method[] methodes = type.getMethods();
for (Method methode : methodes) {
	if (methode.getName().equals(nom)) {
		Class[] parametres = methode.getParameterTypes();
		if (parametres.length == arguments.length) {
			int j = 0;
			boolean idem = true;
			while (idem && j < parametres.length) {
				Class parametre = parametres[j];
				Class argument = arguments[j];
				if (argument.isInstance(parametre)) {
					idem = false;
				}
				j++;
			}
			if (idem) {
				type = methode.getReturnType();
				break;
			}
		}
	}
}

Je déteste les break jetés au loup comme ça. Il faut juste que je vérifie qu'il me sorte bien de la boucle for.

Penses-tu que c'est encore optimisable ?

[herve91]

Les méthodes PrintStream.println() acceptent en entrée un boolean, char, ..., Object, String, long.
par laquelle es-tu intéressé ?
Concernant le paramètre parameterTypes de la méthode Class.getMethod(), la Javadoc dit :

The parameterTypes parameter is an array of Class objects that identify the method's formal parameter types, in declared order

Il te faudra procéder par essais et erreurs jusqu'à trouver la bonne méthode (ou non) mais ça risque d'être un peu compliqué par le jeu des interfaces héritées ou implémentées...

Code :

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

1
2
3
4
5
6
7
8
 
class Test implements I1, I2 ... 
interface I2 extends I1 ...
 
void method(I1 i) {
} 
void method(I2 i) {
}

devrait te renvoyer method(I2) si tu l'appelles avec Test.class

[BiM]

Vu comment fonctionne Java, si je met en paramètre un Comparator à la méthode println, il est censé me prendre la méthode qui a comme paramètre Object. Par contre, si je met un String, il est censé prendre la méthode avec String. Je pensais qu'il y avait une résolution du type, si j'appelle la méthode avec type1, renvoie moi laquelle sera réellement appelée.

Dans tous les cas, une méthode avec un même nom dans une classe n'est pas censée renvoyer deux types différents. Au pire, on n'en mourra pas pour ce à quoi ça sert... (voir suite).

Le but de cet affaire est d'ajouter une règle PMD (ah ouais, le truc pas compliqué du tout), je procède par résolution de type car ce qui a été fait dans PMD au niveau de la résolution de type pour certains types expressions, il y a de jolis TODO "C'est un peu compliqué alors on l'a pas fait", j'adore .

Pour la curiosité, la règle PMD consiste à détecter que chaque catch contient un appel à un logger particulier avec la méthode log de celui-ci. Mais pour cela, il faut résoudre l'ensemble de la ligne avant de dire si on a bien le bon logger.

Plus d'infos : Site officiel de PMD

[LittleBean]

Il y a ce post sur le sujet avec la classe utilitaire qu'il faut (peut être à remettre à jour ... date de 2003 )

http://forums.sun.com/thread.jspa?th...686&forumID=31

Par contre je comprends pas pourquoi tu utilises un logger particulier pour chaque catch

[tchize_]

Vu comment fonctionne Java, si je met en paramètre un Comparator à la méthode println, il est censé me prendre la méthode qui a comme paramètre Object.

Pas entièrement vrais. C'est comme ça que fonctionne le compilateur, la JVM, elle, travaille uniquement avec les type déclarés (sinon bonjour les perfs). Ainsi, prenons exemple les code suivants, dans deux fichiers java distincts.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
 
public class Test1 {
/* 
    public void maMethode(java.util.ArrayList l){
        System.out.println("Méthode avec ArrayList");
    }
    public void maMethode(String s){
        System.out.println("Méthode avec String");
    } */
 
   public void maMethode(java.util.List l){
        System.out.println("Méthode avec List");
    }
    public void maMethode(Object o){
        System.out.println("Méthode avec Object");
    }
}

Code :

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

1
2
3
4
5
6
7
public class Test{
    public static void main(String[] argv){
        Test1 t = new Test1();
        t.maMethode("String");
        t.maMethode(new java.util.ArrayList());
    }
}

On a tout naturellement comme sortie

Code x :

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

1
2
3
4
$ /usr/local/jdk1.6/bin/java Test
Méthode avec Object
Méthode avec List
$

Maintenant, on modifie Test1 et on le recompile sans recompiler Test:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
 
public class Test1 {
 
    public void maMethode(java.util.ArrayList l){
        System.out.println("Méthode avec ArrayList");
    }
    public void maMethode(String s){
        System.out.println("Méthode avec String");
    } 
   /*
   public void maMethode(java.util.List l){
        System.out.println("Méthode avec List");
    }*/
    public void maMethode(Object o){
        System.out.println("Méthode avec Object");
    }
}

La sorti est alors la suivante:

Code x :

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

1
2
3
4
5
$ /usr/local/jdk1.6/bin/java Test
Méthode avec Object
Exception in thread "main" java.lang.NoSuchMethodError: Test1.maMethode(Ljava/util/List;)V
	at Test.main(Test.java:5)
$

On vois que, dans Test, c'est bien respectivement Object et List qui sont cherchés, pas String et ArrayList

[BiM]

Il y a ce post sur le sujet avec la classe utilitaire qu'il faut (peut être à remettre à jour ... date de 2003 )

http://forums.sun.com/thread.jspa?th...686&forumID=31

Par contre je comprends pas pourquoi tu utilises un logger particulier pour chaque catch

Merci pour vos réponses, je crois que je vais rester avec ce que j'ai fait, ça suffit amplement.

Pour répondre à ta question, quand tu travailles sur des applications sensibles (et même sur des non sensibles, il est mieux que chaque trace soit regroupée et que chaque exception soit tracée (au cas où elle nous poserait problème en production)). Cela permet d'éviter d'avoir des sorties en sysout, d'autres en syserr, d'autres dans un logger A et d'autres dans un logger B et de ne pas s'y retrouver !

[tchize_]

Merci pour vos réponses, je crois que je vais rester avec ce que j'ai fait, ça suffit amplement.

Pour répondre à ta question, quand tu travailles sur des applications sensibles (et même sur des non sensibles, il est mieux que chaque trace soit regroupée et que chaque exception soit tracée (au cas où elle nous poserait problème en production)). Cela permet d'éviter d'avoir des sorties en sysout, d'autres en syserr, d'autres dans un logger A et d'autres dans un logger B et de ne pas s'y retrouver !

Cette règle PMD est un peu brutale En l'occurence, il est tout aussi propre et courant de repropager plus haut l'exception, éventuellement wrappée comme cause d'un autre, sinon c'est vite les fichiers de log explosifs (il est très courrant d'avoir des excepton dans le cadre d'un fonctionnement normal), si tu génère une exception et que tu la loggue trois vois à cause de la repropagation toutes les 10 seconde, à 2k de log par exception, tu génère 51M de logs par jour

Maintenant, évidement, si tu fais se taire les logguers en temps normal, c'est une autre chose :p

[BiM]

Cette règle PMD est un peu brutale En l'occurence, il est tout aussi propre et courant de repropager plus haut l'exception, éventuellement wrappée comme cause d'un autre, sinon c'est vite les fichiers de log explosifs (il est très courrant d'avoir des excepton dans le cadre d'un fonctionnement normal), si tu génère une exception et que tu la loggue trois vois à cause de la repropagation toutes les 10 seconde, à 2k de log par exception, tu génère 51M de logs par jour

Maintenant, évidement, si tu fais se taire les logguers en temps normal, c'est une autre chose :p

Au vu des applis concernées, la règle est plutôt utile car les exceptions ne sont jamais "throwé", bref, la règle peut être ignorée au pire

[LittleBean]

Pour répondre à ta question, quand tu travailles sur des applications sensibles (et même sur des non sensibles, il est mieux que chaque trace soit regroupée et que chaque exception soit tracée (au cas où elle nous poserait problème en production)). Cela permet d'éviter d'avoir des sorties en sysout, d'autres en syserr, d'autres dans un logger A et d'autres dans un logger B et de ne pas s'y retrouver !

Je ne remets pas en cause l'utilisation de logger

Je me demandais ce que tu entendais par :

que chaque catch contient un appel à un logger particulier

Tu fais une surcouche de ton logger avec une méthode paramétrée par type d'exception ?


Pour ta règle pmd pourquoi ne pas simplement vérifier que le catch n'est pas vide ? Si ce n'est pas vide le développeur y a 'réfléchi' ... donc ça devrait pas être du n'importe quoi non ?

[BiM]

Non, il y a un appel spécifique au logger, mais pas un par type. Cependant, des fois ils sont vides, des fois ils contiennent un printStackTrace, un sysout ou un syserr, d'autres fois une (ou plusieurs) action(s) diverse(s) et parfois, le logger est bien appelé...