An Overview of AspectJ

Kiczales, Gregor; Hilsdale, Erik; Hugunin, Jim; Kersten, Mik; Palm, Jeffrey; Griswold, William G.

doi:10.1007/3-540-45337-7_18

Cited by 1,779 publications

(1,494 citation statements)

References 16 publications

Supporting

Mentioning

1,419

Contrasting

Unclassified

Order By: Relevance

“…We based our experiment on AspectJ [8], an aspect-oriented programming environment for the Java language. In AspectJ, the join points are certain well-defined points in the execution flow of a Java program.…”

Section: Aspectjmentioning

confidence: 99%

AOP: Does It Make Sense? The Case of Concurrency and Failures

Kienzle

Guerraoui

2002

ECOOP 2002 — Object-Oriented Programming

View full text Add to dashboard Cite

Abstract. Concurrency and failures are fundamental problems in distributed computing. One likes to think that the mechanisms needed to address these problems can be separated from the rest of the distributed application: in modern words, these mechanisms could be aspectized. Does this however make sense?This paper relates an experience that conveys our initial and indeed biased intuition that the answer is in general no. Except for simple academic examples, it is hard and even potentially dangerous to separate concurrency control and failure management from the actual application.We point out the very facts that (1) an aspect-oriented language can, pretty much like a macro language, be beneficial for code factorization (but should be reserved to experienced programmers), and (2) concurrency and failures are particularly hard to aspectize because they are usually part of the phenomenon that objects should simulate. They are in this sense different than other concerns, like for instance tracing, which might be easier to aspectize.

show abstract

Section: Aspectjmentioning

confidence: 99%

AOP: Does It Make Sense? The Case of Concurrency and Failures

Kienzle

Guerraoui

2002

ECOOP 2002 — Object-Oriented Programming

View full text Add to dashboard Cite

show abstract

“…There are no a priori limitations on these qualifiers; they can be any symbols that the MethodCombination objects can recognize. As in CLOS and Aspect/J, we provide some stock MethodCombination objects that implement before, after, and around methods that execute before, after, or before-and-after other methods in response to a single message send [Brant 1998, Kiczales 2001. We also provide a MethodCombination that emulates the Beta [Kristensen 1990] convention of executing methods from innermost to outermost.…”

Section: Methods Qualifiers -Extending Methods Combinationsmentioning

confidence: 99%

“…Our design, as well as the designs of Smalltalk and CLOS, for that matter, is distinguished from more recent work based upon Java derivatives [Boyand 1977, Kiczales 2001 in that given that each is built out of objects, programmers can extend these objects themselves to construct any mechanism they want. It is a testimony to the designers of Smalltalk and CLOS [Gabriel 1991, Bobrow 1993 that principled architectural extensions, rather than inflexible, immutable preprocessor artifice, can be employed to achieve this flexibility.…”

Section: Methods Qualifiers -Extending Methods Combinationsmentioning

confidence: 99%

“…As an amalgam of these systems, the Common Lisp Object System incorporated and popularized multiple dispatch based on generic functions [Bobrow 1988a, Keene 1989. CLOS also incorporated a range of method combinations, although more recently these have also been adopted by aspect-oriented languages, particularly Aspect/J [Kiczales 2001]. Dan Ingalls described the now standard double-dispatch idiom in Smalltalk in what must be the OOPSLA paper with the all-time highest possible power-to-weight ratio [Ingalls 1986].…”

Section: Related Workmentioning

confidence: 99%

See 1 more Smart Citation

Efficient Multimethods in a Single Dispatch Language

Foote

Johnson

Noble

2005

ECOOP 2005 - Object-Oriented Programming

View full text Add to dashboard Cite

Abstract. Smalltalk-80 is a pure object-oriented language in which messages are dispatched according to the class of the receiver, or first argument, of a message. Object-oriented languages that support multimethods dispatch messages using all their arguments. While Smalltalk does not support multimethods, Smalltalk's reflective facilities allow programmers to efficiently add them to the language. This paper explores several ways in which this can be done, and the relative efficiency of each. Moreover, this paper can be seen as a lens through which the design issues raised by multimethods, as well as by using metaobjects to build them, can be more closely examined.

show abstract

“…For this reason we chose an aspect-oriented approach for modularizing scope management. This part of STARS is implemented using a (subset of) the Aspect-Oriented Programming features provided by AspectJ [14]. For performance, predictability and safety reasons we stay away from dynamic or esoteric features such as cflow and features that require instance-based aspect instantiation such as perthis and pertarget.…”

Section: Aspects For Memory Management and Real-timementioning

confidence: 99%

Scoped Types and Aspects for Real-Time Java

Andreae

Coady

Gibbs

et al. 2006

ECOOP 2006 – Object-Oriented Programming

View full text Add to dashboard Cite

Abstract. Real-time systems are notoriously difficult to design and implement, and, as many real-time problems are safety-critical, their solutions must be reliable as well as efficient and correct. While higher-level programming models (such as the Real-Time Specification for Java) permit real-time programmers to use language features that most programmers take for granted (objects, type checking, dynamic dispatch, and memory safety) the compromises required for real-time execution, especially concerning memory allocation, can create as many problems as they solve. This paper presents Scoped Types and Aspects for Real-Time Systems (STARS) a novel programming model for real-time systems. Scoped Types give programmers a clear model of their programs' memory use, and, being statically checkable, prevent the run-time memory errors that bedevil models such as RTSJ. Our Aspects build on Scoped Types guarantees so that Real-Time concerns can be completely separated from applications' base code. Adopting the integrated Scoped Types and Aspects approach can significantly improve both the quality and performance of a real-time Java systems, resulting in simpler systems that are reliable, efficient, and correct.

show abstract

An Overview of AspectJ

Cited by 1,779 publications

References 16 publications

AOP: Does It Make Sense? The Case of Concurrency and Failures

AOP: Does It Make Sense? The Case of Concurrency and Failures

Efficient Multimethods in a Single Dispatch Language

Scoped Types and Aspects for Real-Time Java

Contact Info

Product

Resources

About