DOCSLIB.ORG

Aspect-Oriented Programming with Aspectj

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Aspect-Oriented Programming with Aspectj IJCSI International Journal of Computer Science Issues, Vol. 9, Issue 5, No 1, September 2012 ISSN (Online): 1694-0814 www.IJCSI.org 212 Aspect-oriented programming with AspectJ Daniela Gotseva1 and Mario Pavlov2 1 Computer Systems Department, Technical University of Sofia Sofia, Bulgaria 2 Computer Systems Department, Technical University of Sofia Sofia, Bulgaria Pointcut: a construct for selecting join points Abstract Advice: a construct to introduce or alter execution This article describes the fundamental concepts of a complete behaviour AOP system. It discusses the AspectJ language specification and Static crosscutting: constructs for altering the implementation. The article examines the use of the language, as static structure of a system well as its features and tooling support. It lays out a common crosscutting problem to illustrate the general syntax of the Aspect: a module to express all corsscutting traditional AspectJ Language. The development tools of the constructs AspectJ language are described and compared to popular Java development tools. 1.2 Historical perspective Keywords: Aspect-oriented Programming, AspectJ, Aspect- oriented Programming System (AOP), AspectJ Development AspectJ is the first complete AOP system. At the time of Tools (ADT), Eclipse IDE. writing this article, AspectJ is also the best and most widely used AOP system. The initial development of AspectJ was the work of a team at Xerox PARC, led by 1. Introduction Gregor Kiczales. He also coined the terms "crosscutting" and "aspect-oriented programming". After a few releases, Xerox donated AspectJ to the free software community at 1.1 Fundamental concepts http://eclipse.org. A few years later another AOP system (AspectWerkz) merged with AspectJ, adding features, such An aspect-oriented programming system (AOP) is a as annotation based syntax. At the moment, AspectJ has an software system that is a realization of the aspect-oriented alternative implementation (AspectBench), used for programming methodology. In general, a programming experimenting with new features and optimizations. methodology realization consists of two parts: Language specification: an explicit definition of the syntax and semantics of the language 2. AspectJ as an AOP system The AOP language specification defines how programming constructs are expressed. An AOP language must include AspectJ is an extension to the Java programming language constructs for describing data and behaviour, along with that adds AOP capabilities to Java. The AspectJ constructs that describe how to combine data and behavior. implementation consists of the following components [2]: Language reference implementation: a software A compiler (ajc) application that can translate code written in the A debugger (ajdb) language into an executable form. A documentation generator (ajdoc) The AOP language implementation performs the steps A program structure browser (ajbrowser) necessary to convert the source code into executable code Integration with Eclipse, Sun-ONE/Netbeans, according to the language rules. This process is commonly GNU Emacs/XEmacs, JBuilder, and Ant. referred to as compilation. The AspectJ compiler (ajc) is often called a weaver. The A complete AOP system supports the following name originated because of its primary role to weave the fundamental concepts [1, 4-6]: AspectJ extensions into the Java code, that is to weave Join points: identifiable points in the execution of aspects into classes and produce the final executable code. a system AspectJ provides three weaving mechanisms: Copyright (c) 2012 International Journal of Computer Science Issues. All Rights Reserved. IJCSI International Journal of Computer Science Issues, Vol. 9, Issue 5, No 1, September 2012 ISSN (Online): 1694-0814 www.IJCSI.org 213 Source weaving: The source code for aspects and The AspectJ documentation tool (ajdoc) is very similar to classes is fed to the AspectJ compiler/weaver the Java documentation tool (javadoc). It produces similar which produces the final executable code. This output, but also provides additional information, such as mechanism is useful when the entire source code advice affecting a particular method or all code affected by (aspects and classes) is available. It enables both a given aspect, allowing developers to examine easily the the compilation and weaving to be done in one go crosscutting structure of a system. and highly simplifies the building process. Binary weaving: The input to the weaver is in byte-code form, that is classes and aspects are compiled 3. AOP with AspectJ beforehand. The idea is to compile the classes and aspects without weaving and then weave the resulting binary file. In other words, this is a three-step process (see Fig.h 1): 3.1 Implementing a cache 1. Compile classes To describe and illustrate an AOP with AspectJ, we are 2. Compile aspects going to discuss a rather common and wide-spread 3. Weave aspects into classes to produce problem: implementing a cache. A cache is a classical the final binary files crosscutting concern. With traditional object-oriented programming, the caching concern cannot be completely The binary weaving mechanism is very flexible and isolated or separated from the main concern. You can work enables weaving even when some or all of the Java source around this problem to a certain extent leveraging design code is not available, for example the source code is part patterns such as proxy and decorator, but it cannot be of a third party library or for some reason cannot be completely eliminated. compiled alongside the AspectJ code. 2.1 Load-time weaving AOP provides a complete and elegant solution to such a problem. A very simple illustration is shown in code listing A load-time weaver takes compiled classes and aspects, as 1 (Note that this code listing shows three files: well as an XML configuration. The load-time weaver can FileSystem.java, FileSystemCache.java and take various forms, such as JVMTI agent or a classloader. FileSystemCacheAspect.aj): The load-time weaver weaves aspects into classes as they are loaded into the system prior to first use. The XML file Code listing 1: File System Interface. (aop.xml) specifies the weaving configuration. The public interface FileSystem { aop.xml can be placed under the META-INF directory and Collection<File> list(File entry); defined in the MANIFEST.MF as a classpath component. Load-time weaving greatly reduces the risk of adopting byte[] getContents(File entry); and experimenting with AOP because it makes switching } AspectJ on and off just a matter of configuration. public interface FileSystemCache { byte[] getContents(File entry); void putContents(File entry, byte[] contents); } 1 public aspect FileSystemCacheAspect { 2 3 private FileSystemCache cache = new FileSystemCacheImpl(); 4 5 pointcut fileSystemAccess(File entry) : execution(public * FileSystem+.get*(File)) && args(entry); 6 7 byte[] around(File entry) : fileSystemAccess(entry) { 8 byte[] contents = cache.getContents(entry); Fig. 1 Three-step process. 9 if(null == contents) { 10 contents = proceed(entry); Copyright (c) 2012 International Journal of Computer Science Issues. All Rights Reserved. IJCSI International Journal of Computer Science Issues, Vol. 9, Issue 5, No 1, September 2012 ISSN (Online): 1694-0814 www.IJCSI.org 214 11 cache.putContents(entry, contents); Table 1: Pointcut Construct Structures. 12 } 13 return contents; Pointcut construct Used to select... 14 } 15 } call(MethodPattern or calls to the methods or ConstructorPattern) constructors execution(MethodPattern executions of methods or or ConstructorPattern) constructors The example shows the traditional AspectJ syntax. The get(FieldPattern) field read access FileSystemCacheAspect contains one pointcut and one advice that are defined on lines 5 and 7 respectively. Each set(FieldPattern) field write access pointcut definition is of the form: handler(TypePattern) catch blocks pointcut pointcutIdentifier : joinPointSelectionCriteria; within(TypePattern) executions of code defined in classes Each advice definition is of the form withincode(MethodPattern executions of code defined in or ConstructorPattern) methods or constructors [ strictfp ] AdviceSpec [ throws typeList ] : initialization(ConstructorP object initializations pointcutIdentifier { body } attern) preinitialization(Construct object pre-initializations where AdviceSpec is one of orPattern) before(formals) staticinitialization(TypePat static initializer executions after(formals) returning [(formal)] tern) after(formals) throwing [(formal)] adviceexecution() all advice executions after(formals) cflow(Pointcut) join points in the control flow of Type around(formals) any join point P picked out by Pointcut, including P itself cflowbelow(Pointcut) join points in the control flow of and where formal refers to a variable binding like those any join point P picked out by used for method parameters, and formals refers to a Pointcut, but not P itself comma-delimited list of formal.[2] this(Type) join points where the currently executing object is an instance of The following line: Type pointcut fileSystemAccess(File entry) : execution(public * target(Type) join points where the target object (the object on which a call FileSystem+.get*(File)) && args(entry); or field operation is applied to) is creates a pointcut with the name fileSystemAccess. The an instance of Type part after the colon is the join point selection criteria. In args(Type) join points where the arguments this case, it will match on execution
Load more

Recommended publications
  • A Brief Introduction to Aspect-Oriented Programming
    R R R A Brief Introduction to Aspect-Oriented Programming" R R Historical View Of Languages" R •# Procedural language" •# Functional language" •# Object-Oriented language" 1 R R Acknowledgements" R •# Zhenxiao Yang" •# Gregor Kiczales" •# Eclipse website for AspectJ (www.eclipse.org/aspectj) " R R Procedural Language" R •# Also termed imperative language" •# Describe" –#An explicit sequence of steps to follow to produce a result" •# Examples: Basic, Pascal, C, Fortran" 2 R R Functional Language" R •# Describe everything as a function (e.g., data, operations)" •# (+ 3 4); (add (prod 4 5) 3)" •# Examples" –# LISP, Scheme, ML, Haskell" R R Logical Language" R •# Also termed declarative language" •# Establish causal relationships between terms" –#Conclusion :- Conditions" –#Read as: If Conditions then Conclusion" •# Examples: Prolog, Parlog" 3 R R Object-Oriented Programming" R •# Describe " –#A set of user-defined objects " –#And communications among them to produce a (user-defined) result" •# Basic features" –#Encapsulation" –#Inheritance" –#Polymorphism " R R OOP (cont$d)" R •# Example languages" –#First OOP language: SIMULA-67 (1970)" –#Smalltalk, C++, Java" –#Many other:" •# Ada, Object Pascal, Objective C, DRAGOON, BETA, Emerald, POOL, Eiffel, Self, Oblog, ESP, POLKA, Loops, Perl, VB" •# Are OOP languages procedural? " 4 R R We Need More" R •# Major advantage of OOP" –# Modular structure" •# Potential problems with OOP" –# Issues distributed in different modules result in tangled code." –# Example: error logging, failure handling, performance
    [Show full text]
  • Smart Execution of Distributed Application by Balancing Resources in Mobile Devices
    ALMA MATER STUDIORUM - UNIVERSITÀ DI BOLOGNA SCUOLA DI INGEGNERIA E ARCHITETTURA DISI INGEGNERIA INFORMATICA TESI DI LAUREA in Reti di Calcolatori M Smart execution of distributed application by balancing resources in mobile devices and cloud-based avatars CANDIDATO: RELATORE: Giacomo Gezzi Chiar.mo Prof. Ing. Antonio Corradi CORRELATORE: Chiar.mo Prof. Cristian Borcea Anno Accademico 2014/2015 Sessione III 2 Abstract L’obiettivo del progetto di tesi svolto e` quello di realizzare un servizio di livello middleware dedicato ai dispositivi mobili che sia in grado di fornire il supporto per l’offloading di codice verso una infrastruttura cloud. In particolare il progetto si concentra sulla migrazione di codice verso macchine virtuali dedicate al singolo utente. Il sistema operativo delle VMs e` lo stesso utilizzato dal device mobile. Come i precedenti lavori sul computation offloading, il progetto di tesi deve garantire migliori per- formance in termini di tempo di esecuzione e utilizzo della batteria del dispositivo. In particolare l’obiettivo piu` ampio e` quello di adattare il principio di computation offloading a un contesto di sistemi distribuiti mobili, miglio- rando non solo le performance del singolo device, ma l’esecuzione stessa dell’applicazione distribuita. Questo viene fatto tramite una gestione di- namica delle decisioni di offloading basata, non solo, sullo stato del de- vice, ma anche sulla volonta` e/o sullo stato degli altri utenti appartenenti allo stesso gruppo. Per esempio, un primo utente potrebbe influenzare le decisioni degli altri membri del gruppo specificando una determinata richiesta, come alta qualita` delle informazioni, risposta rapida o basata su altre informazioni di alto livello.
    [Show full text]
  • Towards an Expressive and Scalable Framework for Expressing Join Point Models
    Towards an Expressive and Scalable Framework for expressing Join Point Models Pascal Durr, Lodewijk Bergmans, Gurcan Gulesir, Istvan Nagy University of Twente {durr,bergmans,ggulesir,nagyist}@ewi.utwente.nl ABSTRACT a more fine-grained join point model is required. Moreover, Join point models are one of the key features in aspect- these models are mostly rooted in control flow and call graph oriented programming languages and tools. They provide information, but sometimes a pointcut expression based on software engineers means to pinpoint the exact locations in data flow or data dependence is more suitable. programs (join points) to weave in advices. Our experi- ence in modularizing concerns in a large embedded system This paper proposes an expressive and scalable fine-grained showed that existing join point models and their underlying framework to define join point models that incorporate both program representations are not expressive enough. This data and control flow analysis. One can subsequently specify prevents the selection of some join points of our interest. In a pointcut language which implements (part of) this join this paper, we motivate the need for more fine-grained join point model. Allowing different implementation strategies point models within more expressive source code represen- and language independence is the strength of this model. tations. We propose a new program representation called a program graph, over which more fine-grained join point The paper is structured as follows: First, we will motivate models can be defined. In addition, we present a simple lan- this research with two example concerns we encountered in guage to manipulate program graphs to perform source code our IDEALS[6] project with ASML[2].
    [Show full text]
  • Flowr: Aspect Oriented Programming for Information Flow Control in Ruby
    FlowR: Aspect Oriented Programming for Information Flow Control in Ruby Thomas F. J.-M. Pasquier Jean Bacon Brian Shand University of Cambridge Public Health England fthomas.pasquier, [email protected] [email protected] Abstract Track, a taint-tracking system for Ruby, developed by the SafeWeb This paper reports on our experience with providing Information project [17]. Flow Control (IFC) as a library. Our aim was to support the use However, we came to realise certain limitations of the mech- of an unmodified Platform as a Service (PaaS) cloud infrastructure anisms we had deployed. For example, to enforce the required by IFC-aware web applications. We discuss how Aspect Oriented IFC policy, we manually inserted IFC checks at selected applica- Programming (AOP) overcomes the limitations of RubyTrack, our tion component boundaries. In practice, objects and classes are the first approach. Although use of AOP has been mentioned as a natural representation of application components within an object possibility in past IFC literature we believe this paper to be the oriented language and it seems natural to relate security concerns first illustration of how such an implementation can be attempted. with those objects. We should therefore associate the primitives and We discuss how we built FlowR (Information Flow Control for mechanisms to enforce IFC with selected objects. Furthermore, we Ruby), a library extending Ruby to provide IFC primitives using wish to be able to assign boundary checks on any class or object AOP via the Aquarium open source library. Previous attempts at without further development overhead. We also wish to be able providing IFC as a language extension required either modification to exploit the inheritance property to define rules that apply to of an interpreter or significant code rewriting.
    [Show full text]
  • Design Pattern Implementation in Java and Aspectj
    Design Pattern Implementation in Java and AspectJ Jan Hannemann Gregor Kiczales University of British Columbia University of British Columbia 201-2366 Main Mall 201-2366 Main Mall Vancouver B.C. V6T 1Z4 Vancouver B.C. V6T 1Z4 jan [at] cs.ubc.ca gregor [at] cs.ubc.ca ABSTRACT successor in the chain. The event handling mechanism crosscuts the Handlers. AspectJ implementations of the GoF design patterns show modularity improvements in 17 of 23 cases. These improvements When the GoF patterns were first identified, the sample are manifested in terms of better code locality, reusability, implementations were geared to the current state of the art in composability, and (un)pluggability. object-oriented languages. Other work [19, 22] has shown that implementation language affects pattern implementation, so it seems The degree of improvement in implementation modularity varies, natural to explore the effect of aspect-oriented programming with the greatest improvement coming when the pattern solution techniques [11] on the implementation of the GoF patterns. structure involves crosscutting of some form, including one object As an initial experiment we chose to develop and compare Java playing multiple roles, many objects playing one role, or an object [27] and AspectJ [25] implementations of the 23 GoF patterns. playing roles in multiple pattern instances. AspectJ is a seamless aspect-oriented extension to Java, which means that programming in AspectJ is effectively programming in Categories and Subject Descriptors Java plus aspects. D.2.11 [Software Engineering]: Software Architectures – By focusing on the GoF patterns, we are keeping the purpose, patterns, information hiding, and languages; D.3.3 intent, and applicability of 23 well-known patterns, and only allowing [Programming Languages]: Language Constructs and Features – the solution structure and solution implementation to change.
    [Show full text]
  • Weaving Eclipse Applications
    Weaving Eclipse Applications Fabio Calefato, Filippo Lanubile, Mario Scalas, 1 Dipartimento di Informatica, Università di Bari, Italy {calefato, lanubile, scalas}@uniba.it Abstract. The Eclipse platform fully supports the ideas behind software components: in addition it also adds dynamic behavior allowing components to be added, replaced or removed at runtime without shutting the application down. While layered software architectures may be implemented by assembling components, the way these components are wired together differs. In this paper we present our solution of Dependecy Injection, which allows to build highly decoupled Eclipse applications in order to implement real separation of concerns by systemically applying Aspect Oriented Programming and the Model-View-Presenter pattern, a variant of the classic Model-View-Controller. Keywords: Eclipse, Aspect Oriented Programming, Dependency Injection. 1 Introduction The Dependency Inversion Principle [19] (DIP) states that (both high and low level) software parts should not depend on each other’s concrete implementation but, instead, be based on a common set of shared abstractions: one application of the DIP is the Dependency Injection, also called Inversion of Control (IoC) [11]. From an architectural perspective, DI allows to explicit the dependencies between software components and provides a way to break the normal coupling between a system under test and its dependencies during automated testing [25]. This is possible because the software is composed by aggregating simpler, loosely coupled objects that are more easily unit-testable [32]. Additionally, by separating the clients by their dependencies, we also make their code simpler because there is no need for them to search for their collaborators.
    [Show full text]
  • Static Versus Dynamic Polymorphism When Implementing Variability in C++
    Static Versus Dynamic Polymorphism When Implementing Variability in C++ by Samer AL Masri A thesis submitted in partial fulfillment of the requirements for the degree of Master of Science Department of Computing Science University of Alberta c Samer AL Masri, 2018 Abstract Software Product Line Engineering (SPLE) creates configurable platforms that can be used to efficiently produce similar, and yet different, product vari- ants. To implement SPLs, multiple variability implementation mechanisms have been suggested, including polymorphism. In this thesis, we talk about the trade-offs of using static versus dynamic polymorphism through a case study of IBM’s open-source Eclipse OMR project. Eclipse OMR is an open-source C++ framework for building robust lan- guage runtimes. To support the diverse languages and architectures targeted by the framework, OMR’s variability implementation uses a combination of build-system variability and static polymorphism. OMR developers now real- ize that their current static polymorphism implementation has its drawbacks and are considering using dynamic polymorphism instead. In order to study the trade-offs of using different kinds of polymorphism in OMR, it is crucial to collect function information and overload/override statistics about the current code base. Hence, we create OMRStatistics,a static analysis tool that collects such information about OMR’s source code. Using the information provided by OMRStatistics, OMR developers can make better design decisions on which variability extension points should be switched from static polymorphism to dynamic polymorphism. In addition, we report on our first hand experience of changing the poly- morphism used in OMR’s variability implementation mechanism from static to dynamic, the challenges we faced in the process, and how we overcame them.
    [Show full text]
  • Oracle FLEXCUBE Private Banking Release Notes
    Product Release Notes Oracle FLEXCUBE Private Banking Release 12.1.0.0.0 [April] [2016] Product Release Notes Table of Contents 1. INTRODUCTION ........................................................................................................................................... 1-1 1.1 PURPOSE ..................................................................................................................................................... 1-1 1.2 BACKGROUND/ENVIRONMENT ................................................................................................................... 1-1 1.3 THIRD PARTY SOFTWARE DETAILS ............................................................................................................ 1-2 1.4 RELEASE CONTENTS ................................................................................................................................... 1-4 1.5 PRODUCT DOCUMENTATION ....................................................................................................................... 1-5 2. COMPONENTS OF THE RELEASE ........................................................................................................... 2-1 2.1 DOCUMENTS ACCOMPANYING THE SOFTWARE ............................................................................................ 2-1 2.2 SOFTWARE COMPONENTS ........................................................................................................................... 2-1 1. Introduction 1.1 Purpose Purpose of this Release Note is to highlight the
    [Show full text]
  • Aspectj Intertype Declaration Example
    Aspectj Intertype Declaration Example Untangible and suspensive Hagen hobbling her dischargers enforced equally or mithridatise satisfactorily, is Tiebold microcosmical? Yule excorticated ill-advisedly if Euro-American Lazare patronised or dislocate. Creakiest Jean-Christophe sometimes diapers his clipper bluely and revitalized so voicelessly! Here is important to form composite pattern determines what i ended up a crosscutting actions taken into account aspectj intertype declaration example. This structure aspectj intertype declaration example also hold between core library dependencies and clean as well as long. Spring boot and data, specific explanation of oop, it is discussed in aop implementation can make it for more modular. This works by aspectj intertype declaration example declarative aspect! So one in joinpoints where singleton, which is performed aspectj intertype declaration example they were taken. You only the switch aspectj intertype declaration example. That is expressed but still confused, and class methods and straightforward to modular reasoning, although support method is necessary to work being a pointcut designators match join us. Based injection as shown in this, and ui layer and advice, after and after a good to subscribe to a variety of an api. What i do not identical will only this requires an example projects. Which aop aspectj intertype declaration example that stripe represents the join point executes unless an exception has finished, as a teacher from is pretty printer. Additional options aspectj intertype declaration example for full details about it will be maintained. The requirements with references to aspectj intertype declaration example is essential way that? Exactly bud the code runs depends on the kind to advice.
    [Show full text]
  • Aspect-Oriented Programmingprogramming Wes Weimer
    Aspect-OrientedAspect-Oriented ProgrammingProgramming Wes Weimer (slides adapted from Dave Matuszek, UPenn) Programming paradigms Procedural (or imperative) programming Executing a set of commands in a given sequence Fortran, C, Cobol Functional programming Evaluating a function defined in terms of other functions Scheme, Lisp, ML, OCaml Logic programming Proving a theorem by finding values for the free variables Prolog Object-oriented programming (OOP) Organizing a set of objects, each with its own set of responsibilities Smalltalk, Java, Ruby, C++ (to some extent) Aspect-oriented programming (AOP) = aka Aspect-Oriented Software Design (AOSD) Executing code whenever a program shows certain behaviors AspectJ (a Java extension), Aspect#, AspectC++, … Does not replace O-O programming, but rather complements it 2 Why Learn Aspect-Oriented Design? Pragmatics – Google stats (Apr '09): “guitar hero” 36.8 million “object-oriented” 11.2 million “cobol” 6.6 million “design patterns” 3.0 million “extreme programming” 1.0 million “functional programming” 0.8 million “aspect-oriented” or “AOSD” 0.3 million But it’s growing Just like OOP was years ago Especially in the Java / Eclipse / JBoss world 3 Motivation By Allegory Imagine that you’re the ruler of a fantasy monarchy 4 Motivation By Allegory (2) You announce Wedding 1.0, but must increase security 5 Motivation By Allegory (3) You must make changes everywhere: close the secret door 6 Motivation By Allegory (4) … form a brute squad … 7 Motivation By Allegory (5)
    [Show full text]
  • Eclipse Governance Structure
    Eclipse Governance Structure Board of Directors A p p rov es S trateg y , P lans, P olicies E clip se M anag em ent O rg aniz ation E stab lish es th e R oadm ap , Bu ilds th e P latform , Deliv ers th e V ision R eq u irem ents C ou ncil P rop oses T h em es M em b ersh ip at L arg e & P riorities A p p rov es V ision, By law s Bu ilds th e E cosy stem P lanning C ou ncil A rch itectu re C ou ncil E stab lish es P latform Defines & M aintains R elease P lan A rch itectu re S u b com m ittee A S u b com m ittee B P M C 1 P M C 2 P M C 3 P M C 4 P M C 4 P M C 5 P M C 6 P M C 7 Project Management Committees Eclipse Foundation, Inc. Eclipse Development Roadmap ° http://www.eclipse.org/org/councils/roadmap.html ° Communicate the direction and timetable of the Eclipse projects ° Solicits for input from key stakeholders ° Create an open predictable environment to enable planning for commercial adoption ° Predictable schedule of new releases ° Understand technology direction ° Eclipse Roadmap consists of: ° Themes and Priorities ° Schedules ° Architecture Plan ° Will be update every 6 months ° First iteration done March 2005 Eclipse Foundation, Inc. Eclipse Roadmap: Development Councils Strategic Members PMC T&P’s Requirements Council Add-in Providers Market research T h P e r m io e ri s & ti s e & e s s e m ti e ri h o T ri P Platform Release Planning Architecture Council Architecture Plan Council P P M M C C P A l r a c n h s Eclipse Foundation, Inc.
    [Show full text]
  • Creating a Modular Aspectj Foundation for Simple and Rapid Extension Implementation By
    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
    [Show full text]