Discussion :

[LittleBean]

Bonjour à tous,

Alors je suis face à un problème épineux:
- comment récupérer le context local d'une méthode java?
Bon je m'explique

en gros

Code :

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

1
2
3
4
5
	public void toto(Age a) {
 
		Map h = new HashMap();
		// ici h.put("a", a);
	}

Je veux rajouter dans la hashmap les paramètres de la méthode sans que je les connaisse à l'avance.

De même avec les attributs et les variables locales ...

[Antoine_935]

Si j'ai bien compris, tu veux insérer dans la map l'argument de la fonction, avec comme clef le nom qu'il a ?

Partant de l'idée qu'une variable n'est pas liée à son nom, à mon avis c'est plutôt infaisable, mais...
Cherche tjs de ce côté ci: http://java.sun.com/j2se/1.4.2/docs/...ang/Class.html
et plus précisément http://java.sun.com/j2se/1.4.2/docs/...arameterTypes()

[gifffftane]

Tu peux le faire par la techno des Aspect, donc avant ou après l'appel de la méthode.

Impossible à mon avis par les APIs du JDK : rien dans la reflexivité ne te permet de désigner une variable paramètre.

[LittleBean]

Si j'ai bien compris, tu veux insérer dans la map l'argument de la fonction, avec comme clef le nom qu'il a ?

Oui mais la clef est facultative (je peux mettre la string que je veux) c'est l'objet qui est important à conserver.

Partant de l'idée qu'une variable n'est pas liée à son nom, à mon avis c'est plutôt infaisable, mais...

J'avais cherché du côté de cette api et avait conclu que c'était impossible, une confirmation est toujours rassurante

Tu peux le faire par la techno des Aspect, donc avant ou après l'appel de la méthode.

C'est justement ce que je suis en train de tester (AspectJ)

J'ai réussi à récupéré les objets mais pas les noms des poignées ...
ce qui est je pense impossible tant que je me contente de travailler au niveau de la compilation :p


en fait le point où je bute maintenant serais de récupérer les variables locales ..

Merci de vos réponse

[Invité]

Salut,

Là ça devient plus cher
As tu le code source des classes Java ? si oui il faut parser (il existe des parsers tout faits pour Java) et tu pourras récupérer toutes les informations que tu veux.
Si tu n'as que le bytecode, là il faudra utiliser une bibliothèque comme ASM par exemple si ces infos existent toujours dans le bytecode généré (ce qui n#est pas forcément le cas je crois)

A plus

[Patriarch24]

Je veux rajouter dans la hashmap les paramètres de la méthode sans que je les connaisse à l'avance.

Moi ma question c'est : pourquoi faire ?

[LittleBean]

Moi ma question c'est : pourquoi faire ?

en gros pour pouvoir logger le contexte d'appel de la méthode :p, le tout sans toucher le code ....

[Uther]

Moi ma question c'est : pourquoi faire ?

C'est aussi la question que je me pose. Je n'aime déjà pas trop utiliser la réflexion en temps normal. En général on veut simplifier mais on se retrouve avec quelquechose de souvent moins clair à comprendre pour quelqu'un qui ne connait pas le code et plus complexe pour le refactorring et le débuggage.
Mais inspecter la méthode en cours me parait vraiment tordu.

Je pense que tu devrais d'abord vérifier si tu ne peut pas te passer de ce genre de manipulations.

[Patriarch24]

en gros pour pouvoir logger le contexte d'appel de la méthode :p, le tout sans toucher le code ....

Dans ce cas-là, utilise les aspects. C'est typiquement un cas d'utilisation. Fais des recherches sur AspectJ par exemple.

[tchize_]

de toutes facons, de l'extérieur de la méthode, tu ne pourra pas récupérer les variables locale: avant l'appel à la méthode, elle n'existent pas encore. Après l'appel, elles n'existent plus. Il n'y a que pendant que tu y a accès, dans ce cas, choisi à la mains dans tes appels log ce qui te semble judicieux de logguer (le contexte peux être quelque chose d'énorme pour peu que t'y aie de gros objets ) Quand au nom de paramètres, il faut le code source. tu peux pas le faire par réflection! (d'ailleurs, quand t'as pas les sources et que tu implémente une interface en t'aidant des template d'un un ide, il te tappe des noms de paramètres par défaut (arg0, arg1, arg3, ...)

De plus, même pendant, le "contexte" de la méthode peux inclure des variables stockées directement dans les registres, suivant l'humeur du compilateur

[LittleBean]

Patriarch24

Dans ce cas-là, utilise les aspects. C'est typiquement un cas d'utilisation. Fais des recherches sur AspectJ par exemple.

c'est ce que je suis en train de faire

C'est justement ce que je suis en train de tester (AspectJ)

J'ai réussi à récupéré les objets mais pas les noms des poignées ...
ce qui est je pense impossible tant que je me contente de travailler au niveau de la compilation :p

en fait le point où je bute maintenant serais de récupérer les variables locales ..

tchize_

de toutes facons, de l'extérieur de la méthode, tu ne pourra pas récupérer les variables locale: avant l'appel à la méthode, elle n'existent pas encore.

Alors là on arrive à la limite de ma connaissance sur le compilateur

Si j'ai bien compris

Code :

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

1
2
3
4
5
6
 
	private static void test(int i) {
		// TODO Auto-generated method stub
		int celleLa = 100;
		tutu(i);
	}

Dans ce code là si je met un pointcut methods();, puis je récupérer celleLa sur le code ajouté sur la méthode tutu ...

Peut être faut il mieux utiliser les pointcuts?

Quand au nom de paramètres, il faut le code source. tu peux pas le faire par réflection!

Tout à fait d'accord sur ce point ( ni par aspect)

[tchize_]

dans tutu, tu peux récupérer celleLa, mon debuggeur eclipse le fait, masi je sais pas si c'est possible sans démarrer la java en mode debug et en branchant un debuggueur dessus.