Utilisateur:AlucardZeayon/BacASableTraduction

Une page de Wikipédia, l'encyclopédie libre.

AspectJ est une extension orientée aspect, créée à Xerox PARC, pour le langage de programmation Java. Cette extension est disponible dans les projets open-source Eclipse, de manière autonome ou sous forme d'extension pour l'environnement de développement Eclipse. AspectJ est devenu le standard, du fait de son utilisation répandue, pour la Programmation orientée aspect en mettant l'accent sur la simplicité et la facilité de mise en oeuvre pour les utilisateurs finaux. AspectJ se base sur la syntaxe du langage Java et s'intègre aux IDE pour afficher "doute|crosscutting structure|la structure de découpage" depuis sa première publication en 2001. Le tissage d'aspect est géré de manière statique.

Langage de description simple[modifier | modifier le code]

Tout programme Java est compatible AspectJ. Toutefois, AspectJ permet également au programmeurs de définir des constructions spéciales nommées "aspects". Les "aspects" peuvent contenir plusieurs entités inutilisables par des classes standard. On trouve :

aspect VisitAspect {
void Point.acceptVisitor(Visitor v) {
v.visit(this);
}
}
  • "Pointcut" - non traduit par convention ; pourrait se traduire par "Point de césure" - permet au programmeur de spécifier des "Join points" - non traduit par convention ; pourrait se traduire par "Point de jonction" - (définis à des moments clés de l'exécution d'un programme, comme l'appel à une méthode, l'instanciation d'objet ou l'accès à une variable). Tout "poincut" est une expression vérifiant la correspondance d'un "join point".

Par exemple, ce "pointcut" fait correspondre l'exécution de n'importe quelle méthode d'instance d'un objet de type Point dont le nom commence par set :

pointcut set() : execution(* set*(..) ) && this(Point);
  • "Advice" - non traduit par convention - permet au programmeur de spécifier le code à exécuter au "Join point" remplissant la condition d'un "pointcut". Les actions peuvent être exécutées avant, après ou autour du "Join point" spécifié. Ici, l'"advice" rafraîchit l'affichage à chaque fois que quelquechose de l'objet Point est set, grâce au "pointcut" définis plus tôt :
after () : set() {
Display.update();
}

AspectJ supporte également des formes statiques limitées de vérification et réutilisation d'aspect basées sur les "pointcuts" (par héritage). Voir le guide de programmation AspectJ (en anglais) pour une description plus détaillée du langage.

Compatibilité et implémentations d'AspectJ[modifier | modifier le code]

AspectJ a été conçu pour être implémenté de multiples façons, incluant le "doute|source weaving|source weaving", le "doute|bytecode weaving|bytecode weaving" et directement dans la JVM. Dans tous les cas, le programme AspectJ devient un programme Java valide exécuté dans la JVM. Toute classe contenant des "aspects" est compatible bit à bit avec celles n'en contenant pas (dans le but de maintenir une compatibilité avec n'importe quelle classe qui aurait été compilée avec les classes originales n'en contenant pas). Supporter de multiples implémentations permet au langage d'évoluer avec les changements technologiques et être compatible Java garantie la disponibilité de la plateforme.

Les choix de conception et de langage afin de rendre le développement accessible et les programmes déployables ont été la clé de son succès. L'implémentation originale d'AspectJ par Xerox utilisait le "doute|source weaving|source weaving", ce qui requiert l'accessibilité au code source. Quand Xerox a contribué au développement pour Eclipse, AspectJ a été réimplémenté en utilisant le compilateur Java Eclipse et un "doute|bytecode weaver|bytecode weaver" basé sur BCEL, ce qui permit aux développeurs d'écrire des "aspects" pour du code au format binaire (.class). A cette époque, le langage AspectJ était restreint pour supporter un modèle de classe, essentiel pour la compilation incrémentielle et le temps de chargement "doute|weaving|weaving". Ceci permit les intégrations dans les IDE de manière similaire à leurs contreparties Java et autorisa les développeurs à déployer les "aspects" sans altérer le processus de compilation. Ceci conduit à une adoption croissante, surtout qu'AspectJ devint utilisable pour les développeurs Java impatients et les déploiements à l'échelle de l'entreprise. Depuis, l'équipe Eclipse a accru les performances et la justesse, mis à jour le langage AspectJ afin de supporter les caractéristiques du langage Java telles que les génériques et les annotations, et intégré les "aspects" de la même manière que les annotations purement Java d'AspectWerkz.

Le projet Eclipse supporte la ligne de commande et les interfaces Ant. Un projet lié à celui-ci a nettement amélioré le support de l'IDE Eclipse (AJDT) pour AspectJ et les autres fournisseurs de "doute|crosscutting structure| structures de découpage". Le support des IDE emacs, NetBeans et JBuilder est devenu caduque lorsque Xerox les a passé en open-source mais le support pour JDeveloper d'Oracle a vu le jour. Le support des IDE a été la clé pour les développeurs Java utilisant AspectJ et pour la compréhension des "doute|crosscutting structure| structures de découpage".

Références[modifier | modifier le code]


AspectJ compatibility and implementations[modifier | modifier le code]

BEA has offered limited support in a VM for aspect-oriented extensions, but for extensions to be supported in all Java VM's would require agreement through Sun's Java Community Process (see also the java.lang.instrument package available since Java SE 5 which is some kind of common ground for JVM load-time instrumentation).

Academic interest in both the semantics and implementation of aspect-oriented languages has surrounded AspectJ since its release. The leading research implementation of AspectJ is the AspectBench Compiler, or abc; it supports extensions for changing the syntax and semantics of the language and forms the basis for many AOP experiments that the AspectJ team can no longer support, given its broad user base.

Many programmers discover AspectJ as an enabling technology for other projects they use, most notably Spring AOP.

History and contributors[modifier | modifier le code]

Gregor Kiczales started and led the Xerox PARC team that eventually developed AspectJ; he coined the term "crosscutting". Fourth on the team, Chris Maeda coined the term "aspect-oriented programming." Jim Hugunin and Erik Hilsdale (Xerox PARC team members 12 and 13) were the original compiler and weaver engineers, Mik Kersten implemented the IDE integration and started the Eclipse AJDT project with Adrian Colyer (current lead of the AspectJ project) and Andrew Clement (current compiler engineer).

Jonas Boner and Alex Vasseur engineered the AspectWerkz project, and later contributed to the AspectJ project when it merged in the AspectWerkz annotation style and load-time weaving support.

The AspectBench Compiler was developed and is being maintained as a joined effort of the Programming Tools Group at the Oxford University Computing Laboratory, the Sable Research Group at McGill University and the Institute for Basic Research in Computer Science (BRICS).

See also[modifier | modifier le code]

External links[modifier | modifier le code]

Catégorie:Java Catégorie:Aspect-oriented programming Catégorie:Eclipse

Ce document provient de « https://fr.wikipedia.org/w/index.php?title=Utilisateur:AlucardZeayon/BacASableTraduction&oldid=71839488 ».