controler des codes appelants

bon d'accord le titre de la discussion n'est pas clair.
Je vais essayer d'expliquer le problème.
Je travaille sur un gros projet complexe qui controle des matériels.
Certaines méthodes controlent des ensembles d'opérations : chaque sous-opération est décrite dans une méthode spécifique.
L'opération "englobante" fait des tas de contrôles de sécurité ("puis-je faire ceci et ça tranquillement": on appelle ces méthodes des méthodes "safe" -je suis dans un projet international donc on cause l'espèce d'anglais qui nous sert de viatique-)
les méthodes de bas niveau ne font pas ces controles (dans notre argot elle sont "unsafe")
ces méthodes sont ventilées dans différents packages.

Question: on souhaiterait faire des contrôles par lesquels les codes "unsafe" ne puissent être appelés que depuis de codes "safe" (probablement des contrôles statiques).

Des idées pour implanter un truc de ce genre? (on a quelques idées à demi-cuites et je donnerai ici le résultat final)

"controler des codes appelants"=warning si méthode "UNSAFE" appelée par un code non annoté "SAFE"
(le but n'est pas de faire des contrôles de sécurité blindés mais d'éviter des étourderies par la maintenance)

Merci

Salut,

Tu veux faire ces vérifications quand ?
A l'exécution ou à la compilation ?

A l'exécution je pense que le seul moyen c'est de générer un StackTrace pour vérifier son contenu... mais cela risque d'être assez lourd.


A la compilation je pense il doit y avoir moyen de faire cela avec les Annotation Processor et l'API Compiler Tree : http://docs.oracle.com/javase/6/docs...pi/javac/tree/
Par contre j'ai jamais poussé aussi loin...


a++

Citation:

---

Envoyé par adiGuba

Salut,
Tu veux faire ces vérifications quand ?
A l'exécution ou à la compilation ?

A l'exécution je pense que le seul moyen c'est de générer un StackTrace pour vérifier son contenu... mais cela risque d'être assez lourd.

A la compilation je pense il doit y avoir moyen de faire cela avec les Annotation Processor et l'API Compiler Tree : http://docs.oracle.com/javase/6/docs...pi/javac/tree/
Par contre j'ai jamais poussé aussi loin...

---

de manière réaliste ce serait des verifs statiques ...
On pourrait les lancer quand le code est rendu au gestionnaire de projet (Jenkins, etc.)
j'ai aussi pensé à un Annotation processor ... mais j'ai jamais utilisé :? (ça risque d'être coton vu la complexité de l'arbre des expressions Java)
autre idée: un findbugs plugin (findbugs est lancé systématiquement par le gestionnaire de projet)
cherche retour d'expérience

Citation:

---

Envoyé par professeur shadoko

j'ai aussi pensé à un Annotation processor ... mais j'ai jamais utilisé :? (ça risque d'être coton vu la complexité de l'arbre des expressions Java)

---

J'ai déjà fait pour vérifier l'usage d'annotation... par contre pas pour vérifier tous les appels de méthode...

Citation:

---

Envoyé par professeur shadoko

autre idée: un findbugs plugin (findbugs est lancé systématiquement par le gestionnaire de projet)

---

Je ne connais pas les plugins findbugs, mais il y a des chances que ce soit plus accessible en effet.


a++

Une autre possibilité que je vois, utiliser aspectj. Tu injecte un aspect sur chaque classe @Unsafe qui check si il est bien appelé directement ou indirectement depuis une méthode @Safe ou @Unsafe. Pour éviter les ennuis de performances catastrophiques, une solution serait de n'activer cet aspect que pendant la phase unit test, en utilisant, par exemple du runtime weaving, avec la config de cet aspect dans ressources/test, histoire qu'elle ne touche jamais la prod.


L'avantage c'est que ça devrait être assez rapide à coder: une méthode générique qui checke la pile d'appel (je pense même que aspectj peut te la fournir directement), un aspect de quelques lignes appliqué sur chaque méthode @Safe en before. L'inconvénient, c'est que ça ne check que les piles d'appel qui font déjà l'objet d'un test unitaire. Ca pourrait être compensé en rajoutant le plugin Clover qui s'assurerait que tous les chemins de code sont testés.


En alternative, sans jamais être allé aussi loin non plus, je recommanderais aussi de se brancher sur des post processeur déjà existant. Il y a findbugs, PMD, checkstyle, sonar qui seraient "peut être" des points d'accroche potables.

Cette liste te sera peut-être utile:
http://en.wikipedia.org/wiki/List_of..._analysis#Java

je m'oriente actuellement vers l'écriture d'un "Detector" avec findbugs.
L'avantage c'est que ça s'inscrit bien dans notre chaine de production qui utilise findbugs

le problème c'est que c'est pas terriblement documenté
les exemples que j'ai trouvé sur le Web ne concernent pas des contrôles croisés d'appels de méthodes...
J'ai trouvé des codes qui ressemblent très vaguement à ce que je cherche dans les detectors standard de findbugs ...
mais extrapoler va être une suite d'essais et d'erreurs..:aie:
bref si vous voyez un exemple quelque part qui s'approche de ce genre d'analyse signalez le moi: ça me fera gagner du temps ...
Merci
PS: je suis la discussion avec un bon décalage horaire de 9 heures :?