Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "Developer's guide to building tools on top of AJDT and AspectJ"

(Compilation Units in AJDT: updating for 1.6.2)
m (Known limitations, bugs, and outstanding issues)
Line 121: Line 121:
  
 
Limitation: There is currently no AST support for resolving type bindings:
 
Limitation: There is currently no AST support for resolving type bindings:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=146528
+
[https://bugs.eclipse.org/bugs/show_bug.cgi?id=146528 bug 146528]
  
  
 
----
 
----
 
  
 
== The interface tools are expected to use to drive the AspectJ compiler ==
 
== The interface tools are expected to use to drive the AspectJ compiler ==

Revision as of 19:19, 16 March 2009

This page is intended to aid anyone developing tools to extend or work with AJDT/AspectJ. Please contribute to this page with any relevant information, such as example code using the AJDT and/or AspectJ APIs.

This page is out of date. Our intention is to update this page for AJDT 1.6.1, but we have not had time for this yet. Please understand that some of what is on this page may no longer be correct. If you have any questions, please send them to the mailing list ajdt-dev.



Obtaining crosscutting relationship information from AJDT

If you're developing an eclipse plugin and require access to crosscutting information whenever a project is built, you can register a listener with AJDT. Your plug-in will need to depend on org.eclipse.ajdt.core, org.eclipse.core.resources and org.eclipse.jdt.core, and org.aspectj.weaver. In the org.eclipse.ajdt.core plug-in there is an IAdviceChangedListener interface with a single adviceChanged() method.

Register this with the AJBuilder class like this (in your plug-in's start() method for example):

   AJBuilder.addAdviceListener(new MyAdviceListener()); 

Currently (AJDT 1.6) this is called after every build of an AspectJ project (i.e. every *potential* advice change). In a future release this may be optimized to be only called if the advice has actually changed. AJDT/UI uses this mechanism to update the orange arrow image decorator.

Crosscutting information can then be obtained from the AJModel class. Here's an example with some pseudo code you can adapt:

 public class MyAdviceListener implements IAdviceChangedListener { 
   // get the project
   IProject project = ResourcesPlugin.getWorkspace().getRoot().getProject("MyProject");
 
   public void adviceChanged() {
 
     // the AJProjectModelFacade is a facade into the AspectJ's model.  Provides functionality
     // to query the AspectJ cross cutting model as well as to translate back and forth between
     // JDT elements and AspectJ elements
     AJProjectModelFacade model = AJProjectModelFactory.getInstance().getModelForProject(project);
 
     // You can narrow this to include on certain kinds of relationships
     AJRelationshipType[] relsTypes = AJRelationshipManager.getAllRelationshipTypes();
 
     // check first to see if there is a model
     // will return false if there has not yet beena successful build of this project
     if (model.hasModel()) {
 
       // all relationships for project
       // can also query for relationships on individual elements or compilation units
       List<IRelationship> rels = (List<IRelationship>) model.getRelationshipsForProject(relTypes);
       for (IRelationship rel : rels) {
         // Source is an IProgramElement handle, which refers to a piece of the program in AspectJ's World
         IJavaElement source = model.programElementToJavaElement(rel.getSourceHandle());
         // do something with the source...
         System.out.println(source.getElementName());
 
         for (String targetHandle : (Iterable<String>) rel.getTargets()) {
           // Can have multiple targets
           IJavaElement target = model.programElementToJavaElement(targetHandle);
           // do something with the target...
           System.out.println(target.getElementName());
         }
       }
     }
   }
 }

Several notes about this:

  1. The API may have some minor changes in the future. Please send a message to the ajdt-dev mailing list if anything on this page is out of date.
  2. The AJProjectModelFacade object is a lightweight entrance into the AspectJ world. It is only valid until the next build. So, don't store them. Use them and dispose as needed.
  3. AJProjectModelFacade objects only contain data after the first successful build. You can call the hasModel() method to see if an AspectJ model exists for the project.
  4. As you can see, you get the relationship in both directions. See AJRelationshipManager for the full list of relationships, so you can just ask for the relationship types you're interested in.
  5. IRelationship.getSourceHandle() and IRelationship.getTargets() return Strings that represent AspectJ element handles. You can use the following AJProjectModelFacade methods to convert to model elements:
    • toProgramElement(String) --- returns IProgramElement. From here you can obtain information about the pointcut, intertype element, or declare element.
    • programElementToJavaElement(String) or programElementToJavaElement(IProgramElement) --- returns IJavaElement. From here you can hook into JDT tooling.



Compilation Units in AJDT

JDT creates compilation units (instances of ICompilationUnit) for .java files. AJDT creates compilation units for .aj files, which are instances of AJCompilationUnit (which implements ICompilationUnit). The class AJCompilationUnitManager (in the org.eclipse.ajdt.core plug-in) contains some useful methods relating to this, such as:

 public AJCompilationUnit getAJCompilationUnit(IFile file)

From an AJCompilationUnit you can obtain various structural information such as getAllTypes(). The primary type for ".aj" files is typically an aspect, which is represented by the AspectElement class, which contains aspect-specific methods such as getPointcuts() and getAdvice(). These return further aspect-specific elements such as PointcutElement and AdviceElement.

Since AJDT 1.6.2 for Eclispe 3.4, we use the [[JDT weaving features | Eclipse weaving service] to weave into JDT. One set of join points that are advised are the ones related to the creation of CompilationUnit objects. If the file has is *.aj file, AJCompilationUnit is created instead of a standard Java CompilationUnit.



Using the AspectJ AST parser

Basic example, taken from bug 88861

 import java.util.*;
 import org.aspectj.org.eclipse.jdt.core.dom.*;
 public class Program {
   public static void main(String []argv) {
     ASTParser parser = ASTParser.newParser(AST.JLS2);
     parser.setCompilerOptions(new HashMap());
     parser.setSource(argv[0].toCharArray());
     CompilationUnit cu2 = (CompilationUnit) parser.createAST(null);
     AjNaiveASTFlattener visitor = new AjNaiveASTFlattener();
     cu2.accept(visitor);
     System.err.println(visitor.getResult());
   }
 }

Compile the above and run it:

 java Program "public aspect X { pointcut p(): call(* *(..));}"

then it prints:

 public aspect X {
    pointcut p():call(* *(..));
 }

See also bug 110465: Continue AST work



Known limitations, bugs, and outstanding issues

Limitation: There is currently no AST support for resolving type bindings: bug 146528



The interface tools are expected to use to drive the AspectJ compiler

Work has gone on as part of bug 148190 to update the interface tools are expected to use to drive the AspectJ compiler. This has resulted in the 'core' ajde functionality (which drives the compiler and records progress) to be contained in a new ajde.core AspectJ project with the remaining functionality contained within the ajde project.

For tools who wish to drive the compiler but manage their own ui representation an org.aspectj.ajde.core.AjCompiler instance is needed for each new configuration (project or build configuration). This is created by providing implementations of the other org.aspectj.ajde.core interfaces (IBuildMessageHandler, IBuildProgressMonitor, ICompilerConfiguration and IOutputLocationManager) and then either build() or buildFresh() need to be called on the AjCompiler to drive a compile. For an example of an implementation of this see the MultiProjectIncrementalTests class in the Aspectj tests project or the AJDT implementation in the org.eclipse.ajdt.core and org.eclispe ajdt.ui plugin projects.

For tools who wish to drive the compiler and do not want to manage the ui representation then org.aspectj.ajde.Ajde needs to be initialised. This is initialised with implementations of the same ui related interfaces (EditorAdapter etc) but also with the new ajde.core interfaces (IBuildMessageHandler, IBuildProgressMonitor, ICompilerConfiguration and IOutputLocationManager). There are helper methods within org.aspectj.ajde.Ajde: runBuildInSameThread(..) and runBuildInDifferentThread(..) which should be called when the user has selected to run a build. See the ajbrowser implementation for an example of this usage.

Copyright © Eclipse Foundation, Inc. All Rights Reserved.