Discussion :

[Yannick_from_31]

Bonjour,

j'ai besoin de coder en Java une sorte de générateur de code (aide à l'écriture de scripts plus précisément).

On peut récupérer toutes les méthodes d'une classe par :

Code :

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

1
2
 
Method[] methods = myClass.class.getDeclaredMethods();

mais methods ne contient alors pour les paramètres que les types et pas les noms. Comment accéder aux noms sans faire une lecture du fichier source ?

De plus, je vais devoir générer les paramètres (déclarations et initialisation) pour les ajouter aux appels de méthodes. Je trouve celà lourd à faire et peut-être qu'il existe déjà quelque chose sur ce thème.
Qu'en pensez-vous ?

Pour info, tout ceci s'ajoute à une appli Java existante.

Merci d'avance pour votre aide

[®om]

Effectivement les noms des paramètres ne sont pas gardés (d'ailleurs qd tu fais générer automatiquement les déclarations de méthodes sous eclipse, il met arg0, arg1...).
C'est un truc que je n'ai jamais compris, car il garde les noms des variables locales...

[adiGuba]

Salut,


Les noms des paramètres ne sont pas conservés dans les fichiers *.class, donc tu ne pourras pas les récupérer sans avoir le code source...

Il y a une vielle RFE sur le sujet (BugID 5082475), et il y avait eu des discussions pour intégrer cela dans Java 6, mais cela ne s'est pas fait faute de temps et d'un consensus du groupe d'expert. Ci dessous ce qu'on peut lire dans le rapport final du Java SE 6 Release Contents :

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.

Bref peut-être dans Java 7...

Effectivement les noms des paramètres ne sont pas gardés (d'ailleurs qd tu fais générer automatiquement les déclarations de méthodes sous eclipse, il met arg0, arg1...).
C'est un truc que je n'ai jamais compris, car il garde les noms des variables locales...

Eclipse ne peut te mettre les noms correct que s'il possède les sources des classes. Lorsque ce n'est pas le cas il ne peut te mettre que les arg0, arg1 etc...

Pour info si tu configure eclipse pour qu'il utilise un JDK comme "default JRE", et que tu as installé les sources du JDK alors il te les associes automatiquement avec les classes standard (avec le Ctrl-clic qui te permet d'aller directement voir dans les sources des classes standard )

a++

[Yannick_from_31]

Ok merci des infos

J'ai plus qu'à tout faire à l'ancienne

Au final, cette génération de code qui n'est pas le coeur de mon projet va me prendre beaucoup de temps... tant pis !

[adiGuba]

Au final, cette génération de code qui n'est pas le coeur de mon projet va me prendre beaucoup de temps... tant pis !

Ben si c'est pour du code généré pourquoi t'embêter et ne pas te contenter de créer des paramètres avec des noms bidon style arg0, arg1 etc...

a++

[Yannick_from_31]

Ben si c'est pour du code généré pourquoi t'embêter et ne pas te contenter de créer des paramètres avec des noms bidon style arg0, arg1 etc...

a++

Ce n'est pas possible malheureusement.

En fait, je doit proposer à l'utilisateur final de générer du code afin d'appeler des services particuliers dont il ne connait pas précisément la syntaxe.

Je doit proposer une IHM qui liste ces services (donc paramètres inclus) et qui permet de générer le code nécessaire à leurs appels (init des paramètres inclu).

Donc sans le nom d'un paramètre, l'utilisateur peut ne pas connaître son utilisation surtout dans le cas des types simples (int...).

[adiGuba]

Dans ce cas pourquoi ne pas utiliser une Annotation qui répèterait le nom des paramètres :

Code :

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

1
2
3
4
@Retention(RetentionPolicy.RUNTIME) // Annotation disponible au runtime
@interface ParameterNames {
	String[] value(); // Nom des paramètres
}

Cela implique que chacune des méthodes de ces "services" utilisent une annotation pour décrire leurs paramètres :

Code :

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

1
2
3
4
	@ParameterNames({"x", "y", "width", "height"})
	public void method(int x, int y, int width, int height) {
		// ...
	}

Ensuite tu peux utiliser l'API de reflection pour récupérer l'annotation et ses valeurs :

Code :

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

String[] parameterNames = method.getAnnotation(ParameterNames.class).value();

a++

[Yannick_from_31]

Très bonne idée, je vais tester ça.
Merci.