Third-Party Composition of AOP Mechanisms

Total Page:16

File Type:pdf, Size:1020Kb

Third-Party Composition of AOP Mechanisms Third-Party Composition of AOP Mechanisms Sergei Kojarski M.Sc., Northeastern University, 2004 B.Sc., Perm State Technical University, 2001 A thesis submitted to the Faculty of the Graduate School of Northeastern University in partial fulfillment of the requirements for the degree of Doctor of Philosophy College of Computer and Information Science 2008 Kojarski, Sergei (Ph.D., Computer Science) Third-Party Composition of AOP Mechanisms Thesis directed by Prof. David H. Lorenz Abstract Domain-specific aspect-oriented language extensions offer unique capabilities to deal with a variety of crosscutting concerns. In principle, one should be able to use several of these exten- sions together in a single program. In practice, however, each extension implements its own specialized weaver and the different weavers are incompatible. Even if the weavers were com- patible, combining them is a difficult problem in general, because each extension defines a new language with its own semantics. In this dissertation work, we introduce, analyze and present a solution to the aspect extension composition problem. We present a scalable, general, and practical framework, named AWESOME, for composing aspect weavers. To be scalable, the AWESOME framework supports third-party composition of aspect weavers. To be general, the framework provides means for customizing the composition behavior. Furthermore, to be prac- tically useful, there is no framework-associated degradation in the performance of compiled aspect programs. In memory of John Vlissides — — I was greatly privileged to have had him on my Committee v Acknowledgements I thank my mother for supporting me in my education pursuits. Despite difficult times that our family faced in 1990s my mother managed to give me the best education our home city has to offer. She then stimulated me to apply for PhD studies in United States, and fully supported me in my preparation for graduate exams. During my PhD studies she has been continuously encouraging me in my education and research efforts. I thank my advisor Professor David H. Lorenz for his outstanding contribution to my pro- fessional establishment. David invested enormous amount of time and effort into development of my research skills. I spent most of my studentship standing next to a whiteboard in David’s office, working with him on technical papers, and discussing research ideas. It is this collabo- ration that taught me a discipline of thought, methods of analysis, and presentation techniques that are fundamental for a researcher. David not only developed my skills but also did an exceptional job to ensure that I’m fully supported throughout the duration of my studies. This effort goes far beyond regular administrative activities of a PhD advisor. I’m extremely thankful to David for this support. It gave me peace of mind and time necessary to go deep into the research work. I also thank the other members of my thesis committee, Professors Gene Cooperman, Eric Ernst, David Kaeli, Karl Lieberherr and Dr. John Vlissides, for their valuable comments. I am particularly grateful to Professor Cooperman whose goal was always to support my own goals throughout the completion of this dissertation. The generous support of the National Science Foundation is acknowledged. vi Contents Contents vi List of Tables xii List of Figures xiii List of Listings xv List of Terms xviii List of Symbols xxiii 1 Introduction 1 1.1 Thesis....................................... 2 1.2 TheAspectExtensionCompositionProblem. ....... 3 1.2.1 Thecomponentabstractionproblem . ... 4 1.2.2 Thecompositionspecificationproblem . .... 4 1.2.3 Thecompositionimplementationproblem . ..... 5 1.3 MainResults ................................... 6 1.3.1 PluggableAOP.............................. 6 1.3.2 Thecomponentabstractionproblem . ... 7 1.3.3 Thecompositionspecificationproblem . .... 7 1.3.4 Thecompositionimplementationproblem . ..... 8 vii 1.4 StructureoftheDissertation . ..... 8 2 State of the Art 10 2.1 Aspect-OrientendLanguages . .... 10 2.1.1 AspectJ.................................. 10 2.1.2 AspectWerkz ............................... 14 2.1.3 COOL ................................... 15 2.1.4 Hyper/J.................................. 18 2.2 ModelingAOP .................................. 22 2.3 CompositionofAspects. .. 25 2.4 CompositionofAspectExtensions . ..... 26 2.4.1 Reflex................................... 26 2.4.2 XAspects ................................. 29 2.4.3 AspectJ/5................................. 30 3 Motivation 33 3.1 SignificanceoftheCompositionProblem . ...... 33 3.1.1 AspectDSLs ............................... 35 3.1.2 Reuse................................... 35 3.2 LackofSupportforComposingAspectExtensions . ........ 36 3.2.1 AspectJ/5................................. 37 3.2.2 Reflex................................... 39 3.2.3 XAspects ................................. 41 3.3 ComplexityoftheCompositionProblem . ...... 43 3.3.1 NoCorrectTranslation . 44 3.3.2 NoCorrectSequentialInstrumentation . ..... 45 3.4 Summary ..................................... 46 viii 4 The Component Abstraction Problem 47 4.1 EvolutionofAOPModels ... ... .. ... ... ... .. ... ... ... 49 4.2 Analysis...................................... 51 4.2.1 TheWeavingProblem . ... .. ... ... ... .. ... ... ... 52 4.2.2 TheWeavingPlan ............................ 52 4.2.3 TheWeavingProcess.. ... .. ... ... ... .. ... ... ... 53 4.2.4 Notation ................................. 55 4.3 DesignofaNonreactiveWeavingProcess . ...... 56 4.4 DesignofaReactiveWeavingProcess . ..... 58 4.5 TheDualityofOpenClasses . .. 62 4.5.1 ANonreactiveOCWeavingProcess . 62 4.5.2 AReactiveOCWeavingProcess. 62 4.6 ComposingAspectMechanisms . .. 65 4.6.1 Nonreactiveextensions. 65 4.6.2 Reactiveextensions. 65 4.7 BeyondConceptualModels. .. 67 4.7.1 AbstractDomains............................. 67 4.7.2 TheWeavingProcessasaUnifyingConcept . ... 68 4.7.3 CyclicDependencyinAspectJ . 68 4.7.4 AdvisingAdviceExecution . 68 4.7.5 UntanglingtheBaseandtheAspectMechanisms . ..... 69 4.8 Top-DownClassification . .. 69 4.8.1 SymmetricversusAsymmetricLanguages. .... 69 4.8.2 StaticversusDynamicLanguages . .. 70 4.8.3 StaticversusDynamicSemantics . .. 71 4.9 Top-DownConstruction . 71 4.9.1 Component-BasedDesign . 71 ix 4.9.2 NewAOPFunctionality . 72 4.10Summary ..................................... 73 5 The Composition Specification Problem 75 5.1 Scope ....................................... 76 5.2 Features...................................... 77 5.2.1 JoinPointFeatures ............................ 78 5.2.2 AdviceFeatures ............................. 79 5.3 PatternsofInteraction. .... 81 5.3.1 InfluencingversusInducing . 82 5.3.2 GenuineversusIncidental . 82 5.3.3 ForeignAdvisingversusCo-advising . .... 83 5.4 Co-advisingPatterns ... ... ... .. ... ... ... .. ... ... .. 84 5.5 ForeignAdvisingPatterns . ... 87 5.6 BuildyingaCompositionSpecification . ....... 92 5.6.1 The COOLAJSpecification........................ 93 5.6.2 TheAJWSpecification. 96 5.6.3 The COOLAJWSpecification ...................... 99 5.6.4 ScalabilityandCompleteness . 102 5.7 AnalyzingExistingCompositions . ..... 102 5.8 Summary ..................................... 104 6 The Composition Implementation Problem 106 6.1 SystemDesignRequirements. 108 6.1.1 Granularity ................................ 108 6.1.2 Decoupling................................. 109 6.1.3 Composability .............................. 109 6.1.4 Customizability.............................. 112 x 6.2 AnAspectCompiler ............................... 112 6.3 ACompilerfor COOL ............................... 119 6.3.1 Front-endTranslation. 119 6.3.2 Back-endWeaving ... ... .. ... ... ... .. ... ... ... 122 6.4 AnAspect-OrientedArchitecture. ...... 124 6.4.1 Decoupling ................................ 124 6.4.2 Composability .............................. 127 6.4.3 Customizability.............................. 130 6.5 ImplementationbyRefactoringAspectJ . ....... 133 6.5.1 ImplementingaPlatform. 134 6.5.2 AnAbstractAspectMechanism . 136 6.5.3 ImplementinganAspectJMechanism . 137 6.5.4 ImplementinganAspectWerkzMechanism . 138 6.5.5 Implementing a COOL Mechanism.................... 140 6.6 Summary ..................................... 142 7 Evaluation 143 7.1 Case Study: Composing AspectJ, AspectWerkz, and COOL ........... 145 7.1.1 Implementing COOLAJ.......................... 145 7.1.2 ImplementingAJW .. ... .. ... ... ... .. ... ... ... 148 7.1.3 Implementing COOLAJW ........................ 149 7.2 Third-partyComposition . 149 7.3 Testing....................................... 152 7.3.1 TestingAspectJ.............................. 155 7.3.2 TestingAspectWerkz. 156 7.3.3 Testing COOL ............................... 157 7.3.4 TestingAJW ............................... 158 xi 7.3.5 Testing COOLAJ ............................. 160 7.3.6 Testing COOLAJW............................ 161 7.4 Performance.................................... 163 7.5 Summary ..................................... 165 8 Conclusion 167 8.1 SummaryofContribution. 171 8.2 BenefitsofApproach ............................... 173 8.3 LimitationsofApproach . 173 8.4 FutureDirections ................................ 175 Bibliography 177 A Publications 183 A.1 Pluggable AOP: Designing aspect mechanisms for third-partycomposition. I A.2 Modelingaspect mechanisms: A top-down approach. ......... II A.3 Identifying feature interactions in aspect-oriented frameworks. III A.4 AWESOME: An aspect co-weaving system for composing multiple aspect-oriented extensions.
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]
  • Weaving Ontology Aspects Using a Catalog of Structural Ontology Design Patterns
    Weaving Ontology Aspects Using a Catalog of Structural Ontology Design Patterns Ralph Schäfermeier and Adrian Paschke Corporate Semantic Web Group, Institute of Computer Science, Freie Universität Berlin, Germany {schaef,paschke}@inf.fu-berlin.de http://www.csw.inf.fu-berlin.de Abstract. Modular development of ontologies proves beneficial at dif- ferent stages of the ontology lifecycle. In our previous work, we proposed aspect-oriented ontology development as a flexible approach to modular ontology development and a-posteriori modularization of existing mono- lithic ontologies, inspired by aspect-oriented programming and based on so called cross-cutting concerns. Similar to other formalisms for mod- ular ontologies (e.g. E-Connections), aspect-oriented ontologies rely on an extension of the used ontology language. This derivation from the standard in turn requires specially adapted tools in order to use these ontologies in applications. In this paper, we present an approach to the recombination of aspect-oriented ontology modules to standard OWL 2 ontologies by using an aspect-weaving service. The weaving service relies on a preconfigured catalog of structural ontology design patterns. We show that the use of the weaving service yields syntactically correct and semantically complete ontologies while still allowing ontology developers to fully benefit from modular ontology development. Keywords: Aspect-Oriented Ontology Development, Aspect-Oriented Programming, Ontology Modularization, Ontology Design Patterns 1 Introduction Modular ontology development has proved beneficial when it comes to improve- ment of reasoning and query result retrieval performance, scalability for ontol- ogy evolution and maintenance, complexity management, amelioration of un- derstandability, reuse, context-awareness, and personalization [17]. A significant amount of research work has been dedicated in the field of ontology modular- ization, and various kinds of approaches tackle the problem from different per- spectives.
    [Show full text]
  • The Inheritance Anomaly Revisited
    The Inheritance Anomaly Revisited Ryan J. Wisnesky August 2006 Contents Contents i Preface ii Introduction 1 1 The Inheritance Anomaly and Formal Framework 2 1.1 An Overview of the Inheritance Anomaly . 2 1.2 An Overview of the Framework . 4 2 History-based Guard Languages 7 2.1 History-based guard languages . 7 2.2 Two tweaks . 8 2.2.1 The first tweak: Behavior Preservation . 8 2.2.2 The second tweak: Patching the Proof . 10 2.3 Discussion . 13 2.4 Related Work and Future Directions . 13 2.5 Conclusion . 15 3 Intra-object Concurrency 16 3.1 Methods and Messages . 16 3.1.1 New synchronization constructs . 17 3.1.2 Synchronization, Methods, and Messages . 18 3.2 New Types . 19 3.2.1 Mutual Exclusion: TypesS ............................ 20 3.2.2 Mutual Exclusion and Containment: TypesS .................. 24 3.2.3 TypesT,S ...................................... 25 3.3 Conclusion and Related Work . 27 4 Specification Languages 28 5 Overall Conclusion, Future Directions, and a Note on Typing 29 6 Related Work 30 6.1 Core Papers . 30 i 6.2 Concurrent Formal Systems . 31 6.3 Anomaly Avoidance Mechanisms . 33 6.4 Anomaly Generalizations . 36 6.5 Anomaly Experiences . 36 6.6 Surveys . 37 6.7 Aspect-Oriented Programming . 37 6.8 Others............................................ 38 Bibliography 41 ii Introduction The Inheritance Anomaly has been a thorn in the side of the concurrent object-oriented language community for 15 years. Simply put, the anomaly is a failure of inheritance and concurrency to work well with each other, negating the usefulness of inheritance as a mechanism for code-reuse in a concurrent setting.
    [Show full text]
  • Aspectj in Action, Second Edition
    Introducing AspectJ This chapter covers ■ Writing an AspectJ “Hello, world!” application ■ Becoming familiar with the AspectJ language ■ Weaving mechanisms ■ Integrating with Spring In chapter 1, we focused on general concepts in AOP. With those behind us, we can now look at one specific AOP implementation: AspectJ. AspectJ is an aspect- oriented extension to the Java programming language. Like any AOP implementa- tion, AspectJ consists of two parts: the language specification, which defines the grammar and semantics of the language; and the language implementation, which includes weavers that take various forms such as a compiler and a linker. A weaver produces byte code that conforms to the Java byte-code specification, allowing any compliant Java virtual machine (VM) to execute those class files. The language implementation also offers support for integrated development environments (IDEs), to simplify building and debugging applications. AspectJ started and initially grew as a special language that extends the Java lan- guage with new keywords. It also provided a special compiler that could understand those extensions. But recently, a lot has changed in its form as a language, as well as 27 Licensed to Manning Marketing <[email protected]> 28 CHAPTER 2 Introducing AspectJ in the weaver. First, AspectJ offers an alternative syntax based on the Java annotation facil- ity to express crosscutting constructs. This lets you use a plain Java compiler instead of the special compiler. Second, AspectJ offers new options for weaving classes with aspects. Finally, it has gained a strong foothold in the Spring Framework with several integration options. All these changes have made adoption of AspectJ easier than ever before.
    [Show full text]
  • Aspect-Oriented Software Development for Real-Time and Internet Applications
    International Research Journal of Engineering and Technology (IRJET) e-ISSN: 2395-0056 Volume: 05 Issue: 09 | Sep 2018 www.irjet.net p-ISSN: 2395-0072 Aspect-Oriented Software Development for Real-Time and Internet Applications Ogbonna J. C.1, Nwokoma F. O.2, Nwala K. T.3, Nwandu I. C.4 1,3Reseacher, Dept. of Computer Science, Clifford University Owerrinta, Abia State Nigeria 2,4Reseacher, Dept. of Computer Science, Federal University of Technology Owerri, Imo State Nigeria ---------------------------------------------------------------------***--------------------------------------------------------------------- Abstract - Software development evolution has introduced and increasing the reusability of a software product, which a number of useful software development methods. Efficient in turns results in better software development. modularization of program artifacts that cut across multiple AOP is based on the idea that computer systems are better locations during software development called crosscutting programmed by separately specifying the various concerns concerns have been a major drawback for these software (properties or areas of interest) of a system and some development methods including the almighty Object-Oriented description of their relationships, and then relying on Software Development method. Concerns like recovery, mechanisms in the underlying AOP environment to weave or synchronization, logging, encryption, authentication, compose them together into a coherent program (Elrad, authorization, validation, verification,
    [Show full text]
  • Model-Based Aspect Weaver Construction
    Model-based Aspect Weaver Construction Suman Roychoudhury1, Frédéric Jouault2,1, and Jeff Gray1 1 University of Alabama at Birmingham, Birmingham, AL 35294 {roychous, gray}@cis.uab.edu 2 ATLAS group (INRIA & LINA), University of Nantes, France [email protected] Abstract. This paper describes an approach that combines model engineering with program transformation techniques to construct aspect weavers for general-purpose programming languages. The front-end of the weaver uses a high-level language (i.e., an aspect language) to specify aspects and is designed with a metamodel-based approach using the AMMA toolsuite. The back-end of the weaver uses transformation rules, which are generated from these high-level aspect specifications, to perform the actual low-level weaving. Both the aspect specification (front-end) and transformation rules (back-end) are captured as models within the AMMA platform. The translation from source aspect model to target transformation model is achieved using ATL, which is a model transformation language. Keywords: model transformation, program transformation, model engineering, aspect-oriented-programming, software engineering. 1 Introduction Program transformation systems have been used in the past to construct aspect weavers for programming languages [1]. Program transformation engines (PTEs) such as the Design Maintenance System (DMS) [2], or ASF+SDF [3], provide direct availability of scalable parsers and an underlying low-level transformation framework to modify source programs. This low-level transformation framework (that generally uses term-rewriting or graph-rewriting techniques to modify base code) can form the basis of constructing aspect weavers [4]. In our previous research, we demonstrated how a term-rewriting PTE like DMS can be used to construct an aspect weaver for a general-purpose programming language (GPL) like ObjectPascal [1].
    [Show full text]
  • The Inheritance Anomaly: Ten Years After
    The inheritance anomaly: ten years after Giuseppe Milicia Vladimiro Sassone Chi Spaces Technologies ltd. University of Sussex, UK Cambridge, UK [email protected] [email protected] ABSTRACT Clearly we must make sure that no object is removed from an The term inheritance anomaly was coined in 1993 by Matsuoka empty buffer and that no object is inserted into a full buffer. In a and Yonezawa [15] to refer to the problems arising by the coexis- sequential setting, the burden of ensuring such constraints resides tence of inheritance and concurrency in concurrent object oriented with the buffer’s user. Indeed the buffer is created and used by languages (COOLs). The quirks arising by such combination have one thread only, which is responsible for the state of the object. been observed since the early eighties, when the first experimen- To facilitate usage, the buffer’s methods might return certain er- tal COOLs were designed [3]. In the nineties COOLs turned from ror codes in case of misuse. This approach is not feasible in a research topic to widely used tools in the everyday programming concurrent setting. The buffer will be used concurrently by mul- practice, see e.g. the Java [9] experience. This expository paper ex- tiple clients, leaving each of them no idea on the buffer’s current tends the survey presented in [15] to account for new and widely state. Although it is possible to envisage ad-hoc protocols among used COOLs, most notably Java and C] [19]. Specifically, we il- clients to keep track of the buffer’s state, such a solution is com- lustrate some innovative approaches to COOL design relying on plex and hardly feasible in practice.
    [Show full text]
  • Source-Code Instrumentation and Quantification of Events Robert E
    Source-Code Instrumentation and Quantification of Events Robert E. Filman Klaus Havelund RIACS Kestrel Technology NASA Ames Research Center, MS 269/2 NASA Ames Research Center, MS 269/2 Moffett Field, CA 94035 U.S.A. Moffett Field, CA 94035 U.S.A +1 650–604–1250 +1 650–604–3366 [email protected] [email protected] ABSTRACT particularly with respect to debugging and validating concurrent Aspect-Oriented Programming is making quantified programmatic systems. assertions over programs that otherwise are not annotated to 2. EVENTS receive these assertions. Varieties of AOP systems are Quantification implies matching a predicate about a program. characterized by which quantified assertions they allow, what they Such a predicate must be over some domain. In the permit in the actions of the assertions (including how the actions quantification/implicit invocation papers, we distinguished interact with the base code), and what mechanisms they use to between static and dynamic quantification. achieve the overall effect. Here, we argue that all quantification is over dynamic events, and describe our preliminary work in Static quantification worked over the structure of the program. developing a system that maps dynamic events to transformations That is, with static quantification, one could reference the over source code. We discuss possible applications of this system, programming language structures in a system. Examples of such particularly with respect to debugging concurrent systems. structures include reference to program variables, calls to subprograms, loops, and conditional tests. Categories and Subject Descriptors Many common AOP implementation techniques can be D.3.3 [Programming Languages]: Language Constructs and understood in terms of quantified program manipulation on the Features – aspects.
    [Show full text]
  • Static and Dynamic Approaches to Weaving
    5th Slovakian-Hungarian Joint Symposium on Applied Machine Intelligence and Informatics January 25-26, 2007 ░ Poprad, Slovakia Static and Dynamic Approaches to Weaving Michal Forgáč, Ján Kollár Department of Computers and Informatics, Faculty of Electrical Engineering and Informatics, Technical University of Košice, Letná 9, 042 00 Košice, Slovakia [email protected], [email protected] Abstract: In this paper we present current state of principles and applications in static and dynamic weaving. We are concentrating on static weaving in AspectJ and dynamic weaving in PROSE - PROgrammable extenSions of sErvice. The contribution of this paper is in analyses of both approaches to weaving which we aim to apply as essential mechanisms when constructing software systems by automatic evolution. Keywords: Aspect oriented programming, systems engineering, weaving mechanisms, AspectJ, PROSE1 1 Introduction As a complexity of software systems grows, the need for advanced methods and tools of their specification and the development is the task of the high importance. Object oriented programming (OOP) has increased the productivity of systems rapidly. Benefits of object orientation include support for modular design, code sharing, and extensibility [15]. Object orientation has enabled using inheritance and polymorphism in sence of Strachey's original definition of polymorphism [16]. However, the key issue in application of object approach is that it is not sufficient for crosscutting concerns. One of the fundamental principles of the software engineering is a principle of separation of concerns. A concern is a particular goal, concept, or area of interest, it means that it is in substance semantical concern. From the structural point of view a concern may appear in source code as [4]: This work has been supported by the Scientific grant agency project (VEGA) No.
    [Show full text]
  • Efficient Runtime Aspect Weaving for Java Applications
    Efficient Runtime Aspect Weaving for Java Applications Oscar Rodriguez-Prietoa, Francisco Ortina,∗, Donna O'Sheab aUniversity of Oviedo, Computer Science Department, Calvo Sotelo s/n, 33007, Oviedo, Spain bCork Institute of Technology, Department of Computer Science, Rossa Avenue, Bishopstown, Cork, Ireland Abstract Context: The aspect-oriented paradigm is aimed at solving the code scattering and tangling problem, providing new mechanisms to support better separation of concerns. For specific scenarios where high runtime adaptability is an important requirement, dynamic Aspect-Oriented Programming (AOP) represents a useful tool. With dynamic AOP, components and aspects can be woven and unwoven at runtime, enabling appli- cations greater responsiveness when dealing with different or changing requirements. However, this responsiveness typically incurs a cost in terms of runtime performance and memory consumption. Objective: Build an efficient dynamic aspect weaver for Java that provides the best runtime performance compared to the existing approaches, minimum memory overhead consumption, and similar functionalities to the widespread runtime weavers. Method: We design and implement weaveJ, a dynamic aspect weaver for Java. This dynamic weaver leverages the invokedynamic opcode introduced in Java 7, which allows dynamic relinkage of method and field access. We compare the functionalities of weaveJ with the existing dynamic weavers for Java, and evaluate their runtime performance and memory consumption. Results: weaveJ shows the best runtime performance for all benchmarks and real applications executed. Method interception with invokedynamic is at least 142% faster than the techniques used by the existing runtime weavers. The average cost of dynamic weaving using invokedynamic is only 2.2% for short running programs, and 1.5% for long running applications.
    [Show full text]
  • Comprehensive Aspect Weaving for Java
    Science of Computer Programming 76 (2011) 1015–1036 Contents lists available at ScienceDirect Science of Computer Programming journal homepage: www.elsevier.com/locate/scico Comprehensive aspect weaving for Java Alex Villazón ∗, Walter Binder, Philippe Moret, Danilo Ansaloni Faculty of Informatics, University of Lugano, CH-6900 Lugano, Switzerland article info a b s t r a c t Article history: Aspect-oriented programming (AOP) has been successfully applied to application code Received 20 July 2009 thanks to techniques such as Java bytecode instrumentation. Unfortunately, with existing Received in revised form 19 October 2009 AOP frameworks for Java such as AspectJ, aspects cannot be woven into the standard Java Accepted 2 December 2009 class library. This restriction is particularly unfortunate for aspects that would benefit Available online 29 April 2010 from comprehensive aspect weaving with complete method coverage, such as profiling or debugging aspects. In this article we present MAJOR, a new tool for comprehensive aspect Keywords: weaving, which ensures that aspects are woven into all classes loaded in a Java Virtual Aspect-oriented programming Aspect weaving Machine, including those in the standard Java class library. MAJOR includes the pluggable Bytecode instrumentation module CARAJillo, which supports efficient access to a complete and customizable calling Profiling context representation. We validate our approach with three case studies. Firstly, we Debugging weave existing profiling aspects with MAJOR which otherwise would generate incomplete Detecting memory leaks profiles. Secondly, we introduce an aspect for memory leak detection that also benefits Recreating crashing conditions from comprehensive weaving. Thirdly, we present an aspect subsuming the functionality Java Virtual Machine of ReCrash, an existing tool based on low-level bytecode instrumentation techniques that generates unit tests to reproduce program failures.
    [Show full text]
  • Documentation: Using Aspectc++ for Qt Application Development
    Documentation: Using AspectC++ for Qt Application Development: Ute Spinczyk and Olaf Spinczyk Version 1.0, 28 April 2011 {us,os}@aspectc.org http://www.aspectc.org CONTENTS CONTENTS Contents 1 Introduction4 2 Installation5 3 Aspect Weaving6 4 Examples7 4.1 “Hello Qt World”............................7 4.2 “Connection Graph”..........................9 5 Further Information 11 6 Open Issues 11 3 1 INTRODUCTION 1 Introduction Qt1 is a state-of-the-art cross-platform application and UI framework. It provides C++ class libraries for user interfaces, graphics, networking, database access, and a lot more. Qt applications are typically written in C++ even though interfaces for other languages exist. AspectC++2 extends C++ by specific language constructs that enable Aspect- Oriented Programming. Figure 1: Implementation of crosscutting concerns without and with AOP Figure1 illustrates how a project can benefit from this paradigm: While most concerns of an implementation can be modularized using object-oriented pro- gramming alone, the so-called crosscutting concerns affect many parts. Typical examples are tracing and profiling code. This tangling of code, which implements different concerns, complicates the software maintenance, make re-use more dif- ficult, and contradicts with the principle of Separation of Concerns in general. Aspect Oriented Programming on the other hand allows designers to isolate the crosscutting concerns. In AspectC++ crosscutting concerns can be implemented as aspects. So called pointcuts define where the aspects will take effect, allowing the programmer to inject or replace code in any module. This manual explains how Qt and AspectC++ can be combined. The As- pectC++ tools are developed as an open source project and are available un- der the GPL.
    [Show full text]