XAspects An Extensible System for Domain-Specific Aspect Languages

1. XAspectsAn Extensible System for Domain-Specific Aspect Languages Macneil Shonle (UCSD) Karl Lieberherr (Northeastern University) Ankit Shah (Northeastern University)

2. Talk Overview • What is Aspect-Oriented Programming • Limits of general purpose AOP languages • How domain-specific languages can address these limits • The problems with integrating several domain-specific solutions • Solution: Allow principled extensions to a general purpose AOP language by using XAspects

3. Modular Programming • Every concern goes into its own module • Try to limit coupling between modules

4. Limitations of Modular Programming • Some concerns crosscut module boundaries. • Concerns become tangled. Example: logging, thread synchronization, caching, object marshalling

5. Aspect-Oriented Programming • Encapsulate crosscutting concerns by writing separate aspects. • Aspects then get woven back into the program.

6. Weaving Can happen at run time or compile time. weave

7. interface ShapeI extends Remote { double get_x() throws RemoteException ; void set_x(int x) throws RemoteException ; double get_y() throws RemoteException ; void set_y(int y) throws RemoteException ; double get_width() throws RemoteException ; void set_width(int w) throws RemoteException ; double get_height() throws RemoteException ; void set_height(int h) throws RemoteException ; void adjustLocation() throws RemoteException ; void adjustDimensions() throws RemoteException ; } publicclass Shape implements ShapeI { protected AdjustableLocation loc; protected AdjustableDimension dim; public Shape() { loc = new AdjustableLocation(0, 0); dim = new AdjustableDimension(0, 0); } double get_x() throws RemoteException { returnloc.x(); } void set_x(int x) throws RemoteException { loc.set_x(); } double get_y() throws RemoteException { returnloc.y(); } void set_y(int y) throws RemoteException { loc.set_y(); } double get_width() throws RemoteException { returndim.width(); } void set_width(int w) throws RemoteException { dim.set_w(); } double get_height() throws RemoteException { returndim.height(); } void set_height(int h) throws RemoteException { dim.set_h(); } void adjustLocation() throws RemoteException { loc.adjust(); } void adjustDimensions() throws RemoteException { dim.adjust(); } } class AdjustableLocation { protecteddouble x_, y_; public AdjustableLocation(double x, double y) { x_ = x; y_ = y; } synchronizeddouble get_x() { return x_; } synchronizedvoid set_x(int x) {x_ = x;} synchronizeddouble get_y() { return y_; } synchronizedvoid set_y(int y) {y_ = y;} synchronizedvoid adjust() { x_ = longCalculation1(); y_ = longCalculation2(); } } class AdjustableDimension { protecteddouble width_=0.0, height_=0.0; public AdjustableDimension(double h, double w) { height_ = h; width_ = w; } synchronizeddouble get_width() { return width_; } synchronizedvoid set_w(int w) {width_ = w;} synchronizeddouble get_height() { return height_; } synchronizedvoid set_h(int h) {height_ = h;} synchronizedvoid adjust() { width_ = longCalculation3(); height_ = longCalculation4(); } } • Red text are synchronization concerns • Green text are Remote Method Invocation concerns • In this Java program, the concerns are tangled D: The First Aspect Language(Crista Lopes, 1995)

8. interface ShapeI extends Remote { double get_x() throws RemoteException ; void set_x(int x) throws RemoteException ; double get_y() throws RemoteException ; void set_y(int y) throws RemoteException ; double get_width() throws RemoteException ; void set_width(int w) throws RemoteException ; double get_height() throws RemoteException ; void set_height(int h) throws RemoteException ; void adjustLocation() throws RemoteException ; void adjustDimensions() throws RemoteException ; } publicclass Shape implements ShapeI { protected AdjustableLocation loc; protected AdjustableDimension dim; public Shape() { loc = new AdjustableLocation(0, 0); dim = new AdjustableDimension(0, 0); } double get_x() throws RemoteException { returnloc.x(); } void set_x(int x) throws RemoteException { loc.set_x(); } double get_y() throws RemoteException { returnloc.y(); } void set_y(int y) throws RemoteException { loc.set_y(); } double get_width() throws RemoteException { returndim.width(); } void set_width(int w) throws RemoteException { dim.set_w(); } double get_height() throws RemoteException { returndim.height(); } void set_height(int h) throws RemoteException { dim.set_h(); } void adjustLocation() throws RemoteException { loc.adjust(); } void adjustDimensions() throws RemoteException { dim.adjust(); } } publicclass Shape { protecteddouble x_= 0.0, y_= 0.0; protecteddouble width_=0.0, height_=0.0; double get_x() { return x_(); } void set_x(int x) { x_ = x; } double get_y() { return y_(); } void set_y(int y) { y_ = y; } double get_width(){ return width_(); } void set_width(int w) { width_ = w; } double get_height(){ return height_(); } void set_height(int h) { height_ = h; } void adjustLocation() { x_ = longCalculation1(); y_ = longCalculation2(); } void adjustDimensions() { width_ = longCalculation3(); height_ = longCalculation4(); } } coordinator Shape { selfex adjustLocation, adjustDimensions; mutex {adjustLocation, get_x, set_x, get_y, set_y}; mutex {adjustDimensions, get_width, get_height, set_width, set_height}; } class AdjustableLocation { protecteddouble x_, y_; public AdjustableLocation(double x, double y) { x_ = x; y_ = y; } synchronizeddouble get_x() { return x_; } synchronizedvoid set_x(int x) {x_ = x;} synchronizeddouble get_y() { return y_; } synchronizedvoid set_y(int y) {y_ = y;} synchronizedvoid adjust() { x_ = longCalculation1(); y_ = longCalculation2(); } } class AdjustableDimension { protecteddouble width_=0.0, height_=0.0; public AdjustableDimension(double h, double w) { height_ = h; width_ = w; } synchronizeddouble get_width() { return width_; } synchronizedvoid set_w(int w) {width_ = w;} synchronizeddouble get_height() { return height_; } synchronizedvoid set_h(int h) {height_ = h;} synchronizedvoid adjust() { width_ = longCalculation3(); height_ = longCalculation4(); } } portal Shape { double get_x() {} ; void set_x(int x) {}; double get_y() {}; void set_y(int y) {}; double get_width() {}; void set_width(int w) {}; double get_height() {}; void set_height(int h) {}; void adjustLocation() {}; void adjustDimensions() {}; } Instead of writing this Write this Concerns are now separated D: The First Aspect Language(Crista Lopes, 1995)

9. From D to AspectJ • While the D language only handled synchronization and marshalling concerns it was the inspiration for the AspectJ language. • AspectJ is targeted for general crosscutting concerns…

10. A General Purpose AOPL • AspectJ is an aspect-oriented extension to Java that allows for crosscutting concerns to be decomposed into aspects. • AspectJ supports two models of separation of concerns: • The Join-Point Model (dynamic) • Inter-Type Declarations (static)

11. Join Point Model: Pick out dynamic events when program is running and advise these events. The AspectJ Language aspect Logging { pointcut publicMethods(): execution(public * mypackage..*(..)); Object around(): publicMethods() { System.out.println("Entering " + thisJoinPointStaticPart); Object o = proceed(); System.out.println("Leaving " + thisJoinPointStaticPart + " returning " + o); return o; } }

12. The AspectJ Language • Inter-Type Declarations – makes classes “open.” • Keep similar methods and data together. Can make parts of the implementation aspect private. aspect Rendering { public void Particle.draw(Graphics g) { … } public void Wall.draw(Graphics g) { … } public void Vector.draw(Graphics g) { … } }

13. Separating a Concern:The Visitor Pattern • We want to visit every Book instance from a University instance. This requires two new methods. • AspectJ can encapsulate the visitor pattern in a single aspect by using inter-type declarations. University.visitBooks(BookVisitor v) Library.visitBooks(BookVisitor v)

14. The Visitor Pattern When the class graph is changed, new methods need to be added, and existing ones modified. University.visitBooks(BookVisitor v) College.visitBooks(BookVisitor v) Library.visitBooks(BookVisitor v) Shelve.visitBooks(BookVisitor v)

15. The Visitor Pattern • Even though the aspect is encapsulated its still highly coupled to the class graph. • It is coupled because the visitor concern duplicates information found in the class graph. University.visitBooks(BookVisitor v) College.visitBooks(BookVisitor v) Library.visitBooks(BookVisitor v) Shelve.visitBooks(BookVisitor v)

16. The DAJ Language A domain-specific aspect language can solve the structure dependence problem. declare traversal: void visitBooks(): “from University to Book” (BookVisitor); One declaration for this concern instead of four methods. Reduced redundant information.

17. Karl: Delete this slide. The DAJ Language • Only by using reflection can a structure-shy solution for visitors in AspectJ work because the class graph needs to be known. • The DAJ compiler itself is able to compute the class graph at compile time. • The user of DAJ needs only specify the traversal requirements (e.g. where to start/end the path, what fields to bypass, what fields a visitor must go through, etc. )

18. Domain-Specific Solutions • Domain-specific solutions allow decomposition on a level unachievable with object-oriented or even general purpose aspect-oriented languages. • When applied to the right problems these solutions increase productivity, the problems can be more complex, and the quality can be improved. • One highly successful example are parser generator tools.

19. Karl remarks • Parser Generator Tool? Is this the right word? • Data Binding Tool seems better: JAXB is in this category and won the 2003 Java World Editor’s Choice Award (along with AspectJ) • Data Binding Tool: schema (domain-specific language) defines classes and a language along with a parser and visitors (Print, Equal, Copy, …) to process the parsed object descriptions.

20. Using Multiple Solutions • Most problems cannot be solved entirely with a single domain-specific language. • Yet, using multiple domain-specific languages is also difficult unless they are all tightly integrated or are highly orthogonal. • E.g. a parser generator can be orthogonal to the rest of a program, while a traversal through the program cannot. ( = depends on) Parser Generator Traversal Synchronization Language

21. Circular Dependencies When a domain-specific solution is not orthogonal to the program then it can create circular dependencies. Parser Generator Traversal Synchronization Language Karl J. Lieberherr: Example for multimethods and circular dependency on Traversal Multi-methods

22. Karl tool = plug-in are synonyms • We position the existence of circular dependencies as the main motivation for XAspects? Is this a good strategy? Maybe you are right. • In addition: need multiple communicating tools? • other examples: • we have two traversals and the visitors refer to the “other” traversal? • We have two plug-ins, each adding to the class graph and both having traversals influenced by the addition.

23. What Causes Circular Dependencies? Karl J. Lieberherr: solution = plug-in = tool? All are synonyms • When a domain-specific plug-in needs to both create new interfaces (e.g. new types or methods) and use interfaces generated by other plug-ins. • Tool A uses interfaces generated by Tool B, but Tool B uses interfaces generated by Tool A. If A goes first, it will have compilation errors and vice versa. • If A and B are not tightly integrated, how can they both be used for the same project? Karl:2 What is the difference between the two paragraphs?

24. A Plug-In Architecture • The circular dependency problem of tools can be solved by creating a framework such that the tools communicate using the same language. • The XAspects model is a plug-in architecture to achieve this. • In XAspects, tools read Java code and write AspectJ code as the only means of communication among each other.

25. Karl • Why did we not do this 8 years ago? • DemeterJ (1997) did this with the DemeterJ weaving language but the extensibility currently in XAspects was lacking. • It is now easier with AspectJ, a more powerful weaving language.

26. Removing Dependencies XAspects splits the two different semantics of a domain-specific language: • The language’s external interfaces (structural meaning) • The language’s generated code (behavioral meaning)

27. Karl2 • Structural meaning = external interfaces: Information for other plug-ins • Includes all the information other plug-ins should know to produce their proper behavioral meaning. Could be class graph information • Behavioral meaning using information from other plug-ins • Might also produce more interfaces but only private interfaces that other plug-ins don’t have to know about.

28. Karl2 • Each plug-in needs to clearly specify which context it needs because other plug-ins might modify the context. • Example: A plug-in might add nodes and edges to the class graph that a traversal should not traverse. • Open problem: How to specify the range of applicability of an aspect.

29. Karl: External interfaces = structural meaning. Use only structural meaning. Instead of “semantics” use behavioral meaning Compilation Phases The XAspects model breaks compilation up into six phases: • Source code identification • Generation of external interfaces • Initial bytecode generation • Crosscutting analysis • Generation of semantics • Final bytecode generation

30. Karl: Mention two phases with consistent terminology AJC: XAJC: PLUG-INS: Source Code Identification Generation of STRUCTURAL MEANING Initial Bytecode Generation Crosscutting Analysis Karl: Mention passive collaboration Limited approach: how far does it go is a research topic Generation of Behavioral meaning Final Bytecode Generation Sequence diagram for XAspects model

31. Source Code Identification The XAspects compiler identifies in the source code all program text that belongs to the plug-in and provides that text to the plug-in. aspect(Traversal) BookCollections { declare strategy: everyBook: “from University to Book”; declare traversal: void visitBooks(): everyBook (BookVisitor); } Traversal plug-in

32. Generation of External Interfaces The plug-in generates source files that define the external interface introduced by the language that the plug-in implements. XAspects Compiler aspect(Traversal) BookCollections { declare strategy: everyBook: “from University to Book”; declare traversal: void visitBooks(): everyBook (BookVisitor); } void University.visitBooks() {} ; Traversal plug-in Karl: Empty impl {}

33. Initial Bytecode Generation The AspectJ compiler generates bytecodes from the plug-in defined external interfaces and the remainder of the program. XAspects Compiler Java bytecodes source code + interface stubs AspectJ Compiler

34. Crosscutting Analysis The XAspects compiler provides each plug-in the binary of the program to perform reflection or other analysis on it. Java bytecodes XAspects Compiler Traversal Plug-in AspectJ Compiler

35. Karl: What can we say about the restriction? No structural meaning is generated in phase 2! Generation of Semantics The plug-in generates behavioral changes to the generated program in a restricted form of AspectJ code. XAspects Compiler Traversal Plug-in AspectJ code

36. Final Bytecode Generation Finally, the new behavioral code is woven into the existing code to create the complete program. XAspects Compiler Final Java bytecodes source code + new AspectJ code AspectJ Compiler

37. Implications • A plug-in only needs to know how to read Java bytecodes (or a class graph, or other slices of a whole program) and how to write AspectJ code in order to cooperate with other plug-ins. • With this technique the AspectJ language is extensible, allowing constructs to be added as if they were new language features.

38. The Need for DSALs? We conjecture that the gap between domain-specific aspect languages and general purpose aspect languages will always exist because any general solution cannot cover all possible ways an aspect can crosscut a system. Thus, domain-specific aspect languages can be the route for better separation of concerns.

39. Related Work • Crista Lopes: COOL (ECOOP 94) and RIDL (OO in Operating Systems 95). • Czarnecki and Eisenecker: Generative Programming Book (GP)

40. Domain Specific Language (DSL) • A domain-specific language is a specialized, problem-oriented language. • Need several DSLs to specify a complete application. • General modeling DSLs (e.g., synchronization) • Application oriented DSL (e.g. authorization policy) From: GP 5.5

41. DSLs • Fixed, Separate DSLs • SQL, TEX • Embedded DSLs • Embedded in a general purpose language, e.g. embedded SQL • Modularly composable DSLs (component) • Encapsulated DSLs (e.g., embedded SQL) • Aspectual DSLs (e.g., synchronization)

42. Aspectual DSLs • An aspectual DSL specification influences the semantics of other DSL specifications. • Implementation of modularly composable DSLs requires a common language implementation providing the necessary infrastructure for the language plug-ins (we use AspectJ).

43. Advantages • Of modularly composable over monolithic DSLs • Reusability • Scalability • Fast feature turnover • Have to survive based on their merits

44. Related Work (continued) • Jim Hugunin: • while aspect libraries can provide some domain-specific support in a general purpose AOP language, … some domains warrant the creation of domain-specific languages … • How to extend AspectJ: XAspects is one way

45. Karl: drop first few slides on modularity etc. (Pengcheng) Compare with Eclipse plug-ins. Conclusions: XAspects • An extensible tool to use multiple AOP approaches simultaneously. • An extensible version of DemeterJ and DAJ. • Works well with aspects: Data Binding, Traversal, Visitor, Synchronization. More experimentation is needed with other aspects. • Future work: • How to protect an aspect from misapplication. • add more plug-ins, e.g. a multi-dispatch plug-in, re-engineer JAXB, JAXP, JAXM, etc. Re-engineer Quo. • Connections to other aspect implementations: AspectWerkz, Nanning, JBoss, AOP Alliance, AspectC++, Jac. Karl: Sergei: main difference between Eclipse plug-ins and XAspect plug-ins is that in Eclipse there are fewer extension points while in XAspects we have a finely grained net of extension points (because AspectJ allows more extension points than Java does).