Recuperation du nom des parametres [Résolu]

[Sebastien_INR59]

Bonjour,

J'ai une classe du genre:

Code :

1
2
3
4
5
6
7
8
 
public class MyClass {
 
    public void afficherArguments(String chaine, int a) {
        System.out.println(chaine + a);
    }
 
}

J'aimerais récuperer le nom des paramètres... ex: chaine, a

Dans une autre classe j'ai :

Code :

1
2
3
4
5
6
7
8
9
 
Class uneClasse = Class.forName("MyClass");
 
Method methodes[] = uneClasse.getDeclaredMethods();
 
for (int i = 0; i < methodes.length; i++) {
System.out.println(methodes[i].getName());
System.out.println(methodes[i].getReturnType());
}

Est il possible de recupérer ces noms de parametres de la meme facon ?

Cordialement.

(Suite)

J'ai egalement:

Code :

1
2
3
4
5
6
7
8
 
 //Recuperation des parametres pour chaque methode
Class param[] = methodes[i].getParameterTypes();
 
for (int j = 0; j < param.length; j++) {
mesParam += param[j].getSimpleName() + ";";
 
}

Mais j'obtient seulement le type de ces parametres et non leur nom.

[let_me_in]

je ne veux pas me mêler de tes affaires, mais que va t'apporter de plus de connaitre les noms de parametres ?

[Sebastien_INR59]

Je ne peux m'en passer pour certains tests...

[muad'dib]

Je ne vois pas l'intérêt qu'il y a à connaître les noms des paramètres d'une fonction...
La surcharge de méthodes peut se faire à partir du moment où les types des arguments de la méthode diffèrent. Tu peux à partir de ce concept gérer les arguments que tu veux (int, String etc...)

Expliques-nous ce que tu veux faire au final.

[Sebastien_INR59]

Ce n'est pas une question de surcharge de méthodes les tests dont je parlais...

En fait le projet existe en C# et un "p.Name" suffit. "p" étant un objet ParameterInfo.

Pour des raisons d'intégration avec d'autres outils je dois le passer en Java et là problème...

[muad'dib]

D'accord. Et un exemple d'utilisation de ce p.Name en C# ?

[®om]

Malheureusement il me semble que ça n'est pas possible

(d'ailleurs eclipse te met arg0, arg1... si tu n'as pas lié les sources)

C'est un (gros) oubli

[muad'dib]

Envoyé par ®om

Malheureusement il me semble que ça n'est pas possible

(d'ailleurs eclipse te met arg0, arg1... si tu n'as pas lié les sources)

C'est un (gros) oubli

En fait je ne vois pas du tout l'intérêt de connaître le nom des arguments qui sont passés en paramètre. Ils ne pourront pas te servir de guide dans le code vu que l'on ne peut pas surcharger une fonction en ayant les mêmes types de paramètres. Il doit y avoir un moyen de procéder autrement.

[®om]

Envoyé par muad'dib

En fait je ne vois pas du tout l'intérêt de connaître le nom des arguments qui sont passés en paramètre. Ils ne pourront pas te servir de guide dans le code vu que l'on ne peut pas surcharger une fonction en ayant les mêmes types de paramètres. Il doit y avoir un moyen de procéder autrement.

Par exemple quand tu fais de la génération de code (à partir d'une interface récupérée par introspection), ça rend plus facile la lecture de la génération que des arg0 arg1...

Ça n'est qu'un exemple (c'est dans ce cas où j'ai déjà eu besoin de ça)

[muad'dib]

Envoyé par ®om

Par exemple quand tu fais de la génération de code (à partir d'une interface récupérée par introspection), ça rend plus facile la lecture de la génération que des arg0 arg1...

Ça n'est qu'un exemple (c'est dans ce cas où j'ai déjà eu besoin de ça)

Ok dans ce cas-là effectivement ça serait pratique. Il est vrai que je ne vois rien permettant de récupérer autre chose que le type des variables dans l'API de base.
Concernant les tests que voudrait faire le PO sur ces noms de variables, j'aimerais bien voir.

[adiGuba]

Salut,

Envoyé par ®om

C'est un (gros) oubli

L'accès aux noms des paramètres via la réflection étaient prévus pour Java 6 mais n'a finalement pas été prise en compte.

A l'origine ils voulaient utiliser des annotations pour marquer les méthodes/classes dont les noms de paramètre devaient être conservés...

Mais ils ont finalement conclu que ce serait préférable d'intégrer cela par défaut pour toutes les méthodes, mais que cela impliquait plus de travail et de réflection cela a été reporté dans Java 7...

Tout ceci est indiqué dans la conclusion de la release finale de la JSR 270 :

Reflective access to parameter names

Original description:

Practical experience with annotations has identified situations in which it’d be useful to be able to access the names of method and constructor parameter names. This is particularly relevant to JSRs 181 (Web-Services Metadata) and 224 (JAX-WS 2.0), but it may also be of use in other JSRs such as 255(JMX 2.0) and 274 (Design-Time API for JavaBeans).

This feature will provide access to the names of constructor and method parameters at runtime via the reflection API. To do this effectively will probably require the introduction of a new core annotation, or perhaps a meta-annotation, to identify constructors and methods whose parameter names should be recorded in class files. Otherwise this feature would only work with class files containing full debug information; such class files are larger than is desirable in production settings.

The JSR 270 Expert Group concluded, after a lengthy discussion, that it would be better to support reflective access to all parameter names, by default, rather than require the use of annotations or some other means to request that parameter names be recorded during the compilation of particular classes or interfaces. This is the cleanest approach from the standpoint of language design, it fills in one last gap in Java’s reflection facilities, and it removes any question as to whether or not parameter names will be available to applications.

A consequence of making parameter names available by default is that programs may, intentionally or not, become dependent upon parameter names even though such names are not, strictly speaking, part of the signature of a constructor or method. After this change is made it will be dangerous to rename a parameter of any public or protected method or constructor in any published API. A change of this magnitude deserves wider, and longer-term, publicity and discussion than is possible in the remainder of the Java SE 6 development cycle. The JSR 270 EG therefore recommends that this more complete approach be pursued in Java SE 7.

A noter qu'avec Java 6, les annotations/Processor ce doit être possible de le simuler...

a++

[®om]

Et bien merci adiGuba pour les compléments d'informations

[adiGuba]

Envoyé par adiGuba

A noter qu'avec Java 6, les annotations/Processor ce doit être possible de le simuler...

Comme j'avais en tête de revoir mon tutoriels sur les annotations pour y traiter de la JSR-269 (Annotation Processing) et que je ne trouvais pas d'idée originale pour illustrer mon propos, cette discussion m'a inspiré



J'ai donc fait une annotation @UseParameterNames qui, lorsqu'elle est utilisée sur une classe, permet de générer un fichier contenant les noms des paramètres...

Ensuite à l'exécution il suffit d'utiliser la méthode ParameterTools.getParameterNames(Method) à l'exécution pour récupérer le nom des paramètres...

Exemple :

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
 
import java.lang.reflect.Method;
import com.developpez.adiguba.annotation.ParameterTools;
import com.developpez.adiguba.annotation.UseParameterNames;
 
@UseParameterNames
public class Main {
 
	public static void main(final String... args) {
		// On parcours les méthodes de la classe :
		for (Method method : Main.class.getDeclaredMethods()) {
			System.out.println(method.getName() + " : ");
			// On récupère le type des paramètres 
			Class<?>[] types = method.getParameterTypes();
 
			// On récupère le nom des paramètres (si possible)
			String[] names = ParameterTools.getParameterNames(method);
			if (names!=null) {
				// Et on affiche le tout :
				for (int i=0; i<types.length; i++) {
					System.out.println("\t" + types[i].getCanonicalName() + " " + names[i]);
				}
			}
			System.out.println();
		}
	}
 
 
	public void method() {
	}
 
	public void method(String str) {
	}
 
	public void method(String string, int anInteger) {
	}
 
	public void method(java.util.Date date) {
	}
}

Ce qui affiche en résultat :

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
main :
        java.lang.String[] args
 
method :
 
method :
        java.lang.String str
 
method :
        java.lang.String string
        int anInteger
 
method :
        java.util.Date date

Pour cela il suffit d'inclure le jar contenu dans le fichier-joint au classpath lors de la compilation et de l'exécution. Ce jar utilise le principe un Processor pour générer un fichier properties contenant les noms de paramètres à l'exécution...

Bien entendu c'est uniquement compatible Java 6 et cela nécessite un compilateur strictement conforme (et en particulier qui prend en charge la JSR 269), ce qui n'est pas le cas d'eclipse 3.2 (aucune idée pour le 3.3 je ne l'ai pas encore testé).


C'est codé assez vite et pas optimisé (le fichier Properties est lu à chaque appel de getParameterNames()), et je n'ai pas vraiment le temps de détailler le fonctionnement de tout cela... mais les codes sources sont fourni pour ceux que cela intéresse



J'essayerai de détailler tout cela dans un joli tutoriel lorsque j'aurais un peu de temps


a++

[pseudocode]

Envoyé par adiGuba

aucune idée pour le 3.3 je ne l'ai pas encore testé.

Oui ca marche avec Eclipse 3.3, a condition bien sur d'autoriser les annotations dans les options de compilation du projet.

[adiGuba]

Envoyé par pseudocode

Oui ca marche avec Eclipse 3.3, a condition bien sur d'autoriser les annotations dans les options de compilation du projet.

Ah Cool ! Il va falloir que je teste cela

a++

[pseudocode]

Envoyé par How_to

Menu Eclipse->Project->Properties...

Java Compiler->Annotation Processing
[x] Enable Project Specific settings
[x] Enable Annotation Processing

Java Compiler->Annotation Processing->Factory Path
[x] Enable Project Specific settings
Add Jars -> (indiquer le jar)

OK

et ca marche avec ton jar...

[Sebastien_INR59]

Encore un grand merci pour toute l'aide et informations apportées...