Creating a Modular AspectJ Foundation for Simple and Rapid Extension Implementation by Hristofor Mirche E!I FM" E#AMI$A"I%$ C%MMI""EE dr& C&M& 'oc(isch prof&dr&ir& M& A(sit )*&*+&,*-. Abstract "he current state of aspect/oriented programming 0A%1) has raised concerns regarding arious limitations that A%1 languages ha e& "he issue is that A%1 languages are not robust enough 3hen the basis program is changed& "here are many ne3 proposals for A%1 languages 3ith ne3 features that attempt to restrict or gi e more expressi eness to the programmer in order to force a ne3 context 3here the problems can be mitigated& Some of those languages are designed as extensions of AspectJ. Existing open AspectJ compilers can be used for implementing such an extension, but this can 5uic(ly become a complicated task of extending the complex processes of lexing4 parsing and 3ea ing4 of 3hich the compilers o6er lo3/le el abstractions& "hus4 there is a need for an easily extensible AspectJ foundation for a simpler and faster de elopment of language extensions& !e ha e de eloped such a foundation and in this thesis 3e describe the design of the implementation. !e pro ide an o er ie3 of a testing process to determine its alidity& Finally4 3e implement one proposal for an AspectJ extension and e aluate the extensibility and ease of use of our foundation in comparison to other existing AspectJ compilers& -& Introduction Moti ation& An easy approach to implement an aspect/oriented language 3ould be to extend an existing A%P compiler& "his is not al3ays the best approach4 ho3e er& Existing compilers may force the programmer to use or extend4 components4 that they rely on, 3hich are not tri ial to understand& "hey might ha e not been designed to conform to the same goals you seek or are simply not suited in the context of your design approach& A simpli7ed o er ie3 of the 3or(8o3 of a compiler includes the follo3ing se5uence of operations& "he source 7le is 7rst subjected to a lexical analysis that breaks the stream of characters of the 7le into meaningful :chunks; 0sometimes called tokens2& "he module that does this is called a tokenizer 0or a lexer2& After that4 these to(ens are processed according to the syntactical rules of the language4 speci7ed in a formal grammar& "his part of the process is called parsing and the module that does that is called a parser& Finally4 the parsed input is stored in a speci7c format to be interpreted and used to generate code& In A%14 for example4 this is the step 3here the ad ice information 3ould be 3o en into the original classes on a bytecode le el in a complex process called weaving& Extending existing compilers re5uires some form of manual configuration to these 3ea ing mechanics& "his can pro e to be a signi7cantly inaccessible task for the a erage programmer& !ith our approach4 3e delegate the 3ea ing process to the o<cial AspectJ 3ea er4 thereby freeing users of our implementation to focus more on the syntax of their language extension, rather than the complexity coming from handling the 3ea ing mechanics& Splitting up the aspect information to be 3o en and the base Ja a statements is also accomplished in a clear and concise 3ay through the use of Ja a annotations4 3hich programmers are usually familiar 3ith& "hese t3o factors alone reduce the complexity in using our implementation in comparison to existing AspectJ compilers& For our implementation 3e carried out a model-driven engineering (M=E) approach& More speci7cally4 3e used the EMFText frame3or( to de elop a metamodel and grammar for AspectJ, 3hich 3ere used to generate an AspectJ parser& "o handle the 3ea ing process4 3e can delay it to the point that a class loader loads the class 7les and de7nes them to the Java Virtual Machine 0JVM2& "his approach is called load-time weaving. !ea ing in such a 3ay can be done 3ith the standard AspectJ load/time 3ea er4 3ithout the need for any user modi7cations& "o accomplish this4 ho3e er4 3e 3ould need to :carry; the aspect information to be 3o en in the &class 7le& !e are doing this by transforming the aspect classes to the annotated style introduced in AspectJ ?& "hey can then be compiled 3ith a regular Ja a compiler& "he transformation is achie ed through the use of a model/to/model transformation language& =esign @oals& %ur approach is to implement a 8exible AspectJ grammar 3ith the follo3ing primary design goalsA • simplicity 3e 3ill measure simplicity by the number of concerns 0e&g& lexing4 parsing4 3ea ing) that the programmer has modi7ed o er the lines of code 0B%C) that he has 3ritten 3hen implementing ne3 functionality& • extensi!ility – 3e 3ill measure extensibility by the a erage number of artifacts 0e&g& metamodel entitiesCAS" nodes4 syntax rules2 that the programmer has reused 3hen implementing ne3 functionality& In Section )4 3here 3e explain our implementation of the AspectJ grammar in detail4 3e are further going to discuss the pre/existing AspectJ compilers and ho3 they align 3ith our goals and design process& Contributions& "he contributions of this thesis are the follo3ingA • !e ha e determined criteria for an easily modi7able implementation of an AspectJ compiler suitable for building research/oriented AspectJ extensions& • !e pose our implementation of an exstensible AspectJ grammar conforming to that criteria& • !e e aluate this implementation 3ith a rigorous test process& • !e demonstrate the exstensibility of the implementation by presenting a grammar for an aspect/oriented programming language built on top of it& • !e e aluate our AspectJ foundation 3ith respect to our design criteria by comparing our implementation of functionality from the extension 3ith an implementation of the same functionality build on top of other existing AspectJ compilers& "hesis Structure& "he structure of the thesis is as follo3s& !e 7rst gi e an introduction of the necessary bac(ground information in Section ,4 namely an o er ie3 of AspectJ, model/dri en engineering and EMFText& In the follo3ing section 3e discuss in detail our implementation of an extensible AspectJ grammar& "hese t3o sections are 3ritten in collaboration 3ith George de Heer since 3e both 3or(ed together on the implementation. $ext4 in Section . 3e describe the test case 3e did4 in 3hich 3e implemented the $atural Aspects extension on top of that grammar4 and e aluate4 3hether the design meets our initial criteria of extensibility& Finally4 in Section ? 3e dra3 some conclusions from the experience and discuss possible directions for future 3or(& ,& 'ac(ground AspectJ& Aspect/oriented programming 0A%1) is a paradigm that stri es to increase modularity in programming by separating pieces of the program that rely on or a6ect other parts of it& !hile object/oriented programming 0%%1) o6ers us a 3ay to modulariDe common concerns4 A%1 o6ers a 3ay to modulariDe cross/ cutting concerns in particular& AspectJ is a Ja a extension that supports A%1& It adds a fe3 ne3 concepts to Ja a& A "oin point is a point in the program 8o3& Examples of join points include method calls4 method executions4 constructor executions4 object instantiations and others& A pointcut is a predicate on a set of join points that selects a subset of them. #dvice is code meant to be implicitly executed 3hen the program 8o3 encounters a join point matched by a pointcut& Finally4 an aspect is the module that encapsulates all these ne3 constructs& Another feature of AspectJ called inter-type delcarations, 3hich a6ects the static structure of the program, namely it allo3s the programmer to add 7elds4 methods or interfaces to existing classes4 is outside the scope of our research E-F& Model/dri en engineering& Model/dri en engineering (M=E) is a system de elopment methodology that focuses on the creation and use of models& Models are abstract representations of the concepts related to a speci7c problem domain. A model can describe the entities in a domain, their attributes4 relationships bet3een them and constraints on those relationships& Models are speci7ed using some notation, described in a modeling language. "his notation usually consists of at least a description of the abstract syntax 0i&e& the concepts and relationships2 and a description of the concrete syntax 0i&e& the physical appearance of those concepts and relationships2& "he abstract syntax is commonly de7ned through a metamodel& All the terminology and considerations for models are applicable to the metamodel as 3ell4 as the metamodel is just a model of the model E,F& M=E stri es to increase producti ity in at least three respects& First4 by raising the le el of abstraction M=E closes the semantic gap for domain experts that may other3ise not be experienced in programming 3ith a general/purpose language& Second4 M=E tools can impose constraints and perform model validity checks to detect and pre ent errors early in the de elopment cycle& Model alidity is the process of e aluating the model against di6erent criteria4 either coming from the metamodel or in the form of constraints4 3ritten by the programmer& Bastly4 through the use of code generation and model trans%ormation4 M=E increases :automation; in soft3are de elopment thereby limiting the possibility of human errors& Code generation is the process of generating source code from the model 3hile model transformation is the act of transforming a source model into a target model through the use of transformation rules E)F& "his is the primary reason 3hy 3e 7nd M=E to be particularly good at implementing a language conforming to our design goals& Most M=E tools generate