1 / 21

Session 2: AspectJ

Session 2: AspectJ. Mark Stobbe September 13, 2007. Overview. Ingredients for Aspect Oriented Languages Join Point Model The Big Players Who beats who Language-specific Development-specific Loose ends. Ingredients. Join Point Model Join points Pointcuts Advice Composition Naming

dympna
Télécharger la présentation

Session 2: AspectJ

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Session 2: AspectJ Mark Stobbe September 13, 2007

  2. Overview • Ingredients for Aspect Oriented Languages • Join Point Model • The Big Players • Who beats who • Language-specific • Development-specific • Loose ends

  3. Ingredients • Join Point Model • Join points • Pointcuts • Advice • Composition • Naming • Abstraction and concretization • Exposing state • Inter-type declarations • Weaver

  4. Join points – up-close public class Example { intx; public static voidmain(String[] args) { Example ex = new Example(); ex.func(); } public Example() { x = 10; } public intfunc() { return x; } } 1. Before execution(void Example.main(String[])) 2. Before call(Example()) 3. Before execution(Example()) 4. Before set(int Example.x) 5. After set(int Example.x) 6. After execution(Example()) 7. After call(Example()) 8. Before call(int Example.func()) 9. Before execution(int Example.func()) 10. Before get(int Example.x) 11. After get(int Example.x) 12. After execution(int Example.func()) 13. After call(int Example.func()) 14. After execution(void Example.main(String[])) 1 2 7 8 13 14 3 4 5 6 1-14 within(Example) 9 10 11 10-11 withincode(int Example.func()) 12 10-11 cflowbelow(execution(int Example.func())) 3-6 cflow(execution(Example.new()))

  5. Answering question Question Another question that I have is about precedence. Imagine defining before, after and around advices for the same pointcut, I wonder what the execution order of the advices will be? Will the order be before, around and then after or the other way around? (Alesya) Answer 1. Before 2. Around 3. After

  6. Answering question Question Can you please discuss the primitive pointcutcflow in detail? I am particularly interested in the semantics of the composition of those pointcuts: cflow(P) && cflow(Q) and cflow(P && Q). This is explained briefly in the Programming Guide, but I find it very difficult to understand. Perhaps you can give a clear, concrete example? (Martijn) Answer cflow is the collection of join points flowing from the argument pointcut. This means that cflow(P) && cflow(Q) is the intersection of the two collections, while cflow(P && Q) means that you first combine the pointcuts P and Q, and all the join points flowing from that are in this collection.

  7. Giving example public class Example { public void P() { Q(); } public voidQ() { } public static voidmain(String[] args) { new Example().P(); } } publicaspectExampleAspect { pointcut P(): execution(* Example.P(..)); pointcut Q(): execution(* Example.Q(..)); pointcutflowP(): cflow(P()) && within(Example); pointcutflowQ(): cflow(Q()) && within(Example); pointcutflowPAndflowQ(): cflow(P()) && cflow(Q()) && within(Example); } Flow from P - execution(void Example.P()) Flow from P - call(void Example.Q()) Flow from P - execution(void Example.Q()) Flow from Q - execution(void Example.Q()) Flow from P && flow from Q - execution(void Example.Q())

  8. Answering question Question What is the difference between cflow and cflowbelow, and cflow and within? Is within just a more specific version of cflow? (Martijn) Answer The difference between cflow and cflowbelow is whether the argument pointcut should be taken included or excluded. The difference between within and cflow is that within works on a TypePattern, while cflow works on a Pointcut.

  9. Giving example public class Example { public void P() { Q(); } public voidQ() { } public static voidmain(String[] args) { new Example().P(); } } publicaspectExampleA { pointcut P(): execution(* Example.P(..)); pointcutflowP(): cflowbelow(P()) && within(Example); } publicaspectExampleB { pointcut P(): execution(* Example.P(..)); pointcutflowP(): cflow(P()) && within(Example); } call(void Example.Q()) execution(void Example.Q()) execution(void Example.P()) call(void Example.Q()) execution(void Example.Q())

  10. Answering question Question When you have something like: receptions(void FigureElement.incrXY(int, int)) and the example from Fig. 1 in the 2001-ecoop paper. If you call Line.incrXY(int,int) it will match, but what if that method forwards the call to Point.incrXY(int,int)? Will it match again? And if so, is there a way to prevent this bubbling up effect? Or don't you need this in practice anyway? But at the top of page 17 they seem to say that you can do that with cflow, but it's still a bit unclear. Is this indeed the way to do it? (Christiaan) Answer Line and Point are a subclass of FigureElement, this means the type matches and therefore you will indeed receive multiple matches for Line.incrXY and Point.incrXY. You can always specify precisely Line.incrXY(int,int) in your pointcut, if you only want that specific pointcut. Or you can use cflowbelow to retrieve only the first call to a FigureElement.incrXY call.

  11. Giving example public class Example { public static voidmain(String[] args) { new Line().move(); new Point().move(); } } interfaceFigElem { public voidmove(); } class Line implementsFigElem { Point p; public voidmove() { p.move(); } } class Point implementsFigElem { public voidmove() { } } publicaspectExampleAspect { pointcut all(): execution(* FigElem.move(..)); pointcut first(): all() && !cflowbelow(all()); } • First: execution(void Line.move()) • execution(void Point.move()) • First: execution(void Point.move())

  12. Big Players • For Java • AspectJ • AspectWerkz • JBoss AOP • Spring AOP • For non-Java • AspectC++ • Others, including comparison, can be found here: http://janus.cs.utwente.nl:8000/twiki/bin/view/AOSDNET/CharacterizationOfExistingApproaches @AspectJ Spring 2.0 AOP includes AspectJ

  13. Comparison - Syntax Language-like vs. Annotations vs. XML • Concise and natural • Language support, own compiler • XML more familiar, easier to write tools • Fine-grained annotations Source: MikKersten – AOP Tools comparison

  14. Answering question Question The paper and tutorials on AspectJ say that the three types of advice that are available - before, after and around - allow applying advice to methods. But what if I want to insert a logging statement somewhere in the middle in the method code? Or when I do debugging and I want to see the intermediate results, I would have a log.debug statement inside a method. Is it possible to somehow accomplish that with AspectJ? I could think of writing a pointcut for every logging (debugging) statement that's in the middle of the method. But I was wondering if there is another way of doing this? (Alesya) Answer In AspectJ, no. There are a limited number of possible join points and since Java only allows for annotations outside methods, it is not possible. A workaround would be to extract the code into a method.

  15. Comparison - Join points Expressiveness vs. simplicity • Less join points, less to understand • Regular Expressions, strong but hard to read Source: MikKersten – AOP Tools comparison

  16. Comparison - Weaver Compile-Time vs. Run-Time • Some join points always require RT check, like: cflowandinstanceof • Static-checks makes easy programming • Fast compiling or fast running Source: MikKersten – AOP Tools comparison

  17. Answering question Question At chapter 3.3 in the paper, they state that upon arrival at a join point, all advice in the system is examined to see whether any apply at the join point. It collects all advices and try to match those with the current evaluated method/function. Can this have some sort of influence on the system performance (especially on more advice given)? (Robin) Answer AspectJ tries solve most of these at compile-time. The overhead will then be a simple call to the advice body, which most of the time can be inlined by the virtual machine. Some pointcuts cannot be statically inferred, for example when using cflowor instanceof, these have an additional runtime check. In the paper they claim this overhead is relative small.

  18. Answering question Question At chapter 4 they say that the AspectJ language uses a compiler. At chapter 3.3 they talk about runtime (if I'm correct though). What's the implementation? Is it both a compiler and runtime library or just the compiler? (Robin) Answer Both. The compiler is the static weaver, trying to weave all aspects at compile-time. The runtime library provides some extra classes, for example: JoinPoint. It is also used for runtime pointcuts like cflowand instanceof.

  19. Comparison - IDE • Special AOP support • Normal debugging • No refactoring • No UML Source: MikKersten – AOP Tools comparison

  20. Answering question Question AspectJ and IDE integration: are there tools that allow for easy integration, like some tool that tells given some pointcut where it will crosscut the program (/source code)? Or should every IDE extension implement this logic itself? (Peter) Answer For most editors there are tools written to support AspectJ or similar. These can again be used by developers to build their own tools on top. If you want to build support for your own IDE, AspectJ offers you the ADJE API.

  21. Loose ends Question Is it possible for an aspect to extend another aspect (maybe that would be another way of doing the MoveTracking and Mobile examples?). Or would that just come down to re-using the pointcuts? (Peter) Answer It is possible to create an abstract aspect, which can be implemented by another aspect. This aspect will then have to implement the abstract pointcuts defined in the abstract aspect. It is useful for creating general-purpose aspects.

More Related