Workshops of AOSD'07

Refer to here for all the workshops held at AOSD'07.

Below are the ones that I'm sepecially interested in:

• Workshop on of Asessment of Aspect-Oriented Technologies: The subject are really interesting and worth being noticed by all the researchers and developers. There's a researcher from mainland China in the organization committee. No papers/slides available on-line abouth the workshop.
• Software Engineering Properties of Languages and Aspect Technologies: Evaluation of AO tools and technologies, serving as important criteria for improving existing ones and designing/developing new ones.
• Workshop on Best Practices in Applying Aspect-Oriented Software Development: No one will not be interested in this.
• Foundations Of Aspect-Oriented Languages
• Workshop on Testing Aspect-Oriented Programs: This field is led by an overseas Chinese researcher Dr. Xu.

The workshop I'm intersted the most, but not appearing at AOSD'07 is Modeling and Analysis of Concerns in Software .

AOSD'07 "Report" - By others

Blog Posts About AOSD'07:

• AOSD Demo a success:Can't figure out what exactly the demo is from this post. I guess it is a eclipse plug-in facilitating jps indicating.

• AOSD Conference Day 1:About Glassbox, overhead of load-time weaving, possible usage of AOP for run-time verification/debugging, comment on the keynote "Building Robust System", etc.

• Arriving at AOSD:Inside story about the author attending the conference.

update (22/03/2007）：

• AOSD 2007 Conference: Blog from Object Mentor. The author gave a tutorial on Industry Track.
  

No more...

It seems the academic people are too busy to blog. There are few posts about the conference.

AspectJ Syntax Notes and More…

Note: Some of the following items, especially items in red, are based on my experience with aspectj 1.5.3.200611221118 (AJDT 1.4.1.200611230655) , JVM 1.5.0-b64, and JDT 3.2.0.v20060609m-F7snq1fxia-Z4XP.

• [Nested/Inner Aspect] Nested aspects must be static. An inner aspect has to be static, in order to get rid of the implicit “&& this()” which you get on a perthis-Aspect.
• [Aspect Extension] aspects may only extend abstract aspects. It is an error for a concrete aspect to extend another concrete aspect.
• [Aspect Instantiation] Because advice only runs in the context of an aspect instance, aspect instantiation indirectly controls when advice runs.
• [Aspect Instantiation] The criteria used to determine how an aspect is instantiated is inherited from its parent aspect. If the aspect has no parent aspect, then by default the aspect is a singleton aspect.
• [Aspect Instantiation] Static initialization occurs when the type is loaded (i.e., the Java VM
  loads the resulting class file for Lolo). At that point, the implementation of the before calls the static method aspectOf to access the singleton instance of Lolo.
• [Aspect Instantiation] You can get a NoAspectBoundException when there is a cycle in aspect initialization or static initialization (within one aspect, or between a chain of several aspects), most commonly when an aspect advises its own initializer.
• [Aspect Instantiation] During the constructor of an aspect, calling aspectOf() on that aspect would fail. Because at that moment, no aspect instance has been bound. It is the same reason why in an after() :(execution(AspectA.new())) advice, calling AspectA.aspectOf() would fail. In this case, instead, target can be used to expose the instance of AspectA.
• [Aspect Instantiation] ! Do not advise join points in cflowbelow(execution(AspectA.new())), there are bugs or flaws with aspectj which your advice may reproduce, especially when dynamically determined variable are involved in your advice body. Or don’t define your own aspect constructor, but just use the default aspect constructor, which would make your aspectj code more robust.
• [Advice Execution] ! Exception or Error thrown in advice “before(String[] args) : execution(public static void *.main(String[]))” can’t be captured!
• [Declaration] ! How to declare an error if some join points that are supposed to be captured are actually not captured?
• [PCD] A named pointcut may be defined in either a class or aspect, and is treated as a member of the class or aspect where it is found. As a member, it may have an access modifier such as public or private. Abstract pointcuts may only be declared within abstract aspects. For completeness, a pointcut with a declaration may be declared final. Though named pointcut declarations appear somewhat like method declarations, and can be overridden in subaspects, they cannot be overloaded.
• [PCD] call(Foo.new(..)) can’t be used together with target(*).
• [PCD] Rather than cflow, use lexical-structure based pointcuts, within or withincode, preferablely. It will make the cross-reference view of the AJDT more accurate and less time consuming.

to be continued…

Resources:

1. aspectj doc
2. aspectj-user-request mailing list

Is AOP a Programming paradigm

Edited by: I.Am.Blogger at gmail dot com

Prerequisite:
“A programming paradigm is a paradigmatic style of programming (compare with a methodology which is a paradigmatic style of doing software engineering). A programming paradigm provides (and determines) the view that the programmer has of the execution of the program.”
(http://en.wikipedia.org/wiki/Programming_paradigm)

Yes:
“I would argue that by any reasonable definition of paradigm, AOP is one. You can "think aspects" starting from fairly early in the design process (probably requirements too); you can design and develop those aspects; you can make the code look like the design; the aspects can be treated as independent units, with independently assessable properties and value. All the things that I at least thought made OO a paradigm seem to apply...”
By Gregor Kiczalse(http://aosd.net/pipermail/discuss_aosd.net/2004-July/001001.html)

“…Note that the original meaning of "paradigm" entails the notion that two different paradigms are incompatible, which means that the qualification as paradigms does not depend on whether you can use them independently but rather that you _cannot_ use them together. From this perspective, none of the programming paradigms in computer science are really paradigms, because it's certainly possible to mix them altogether…The analogy that I'd propose is that AOP relates to OOP as OOP relates to imperative programming, and if you describe the move from imperative programming to OOP as a paradigm shift, you also have to describe the move from OOP to AOP as a paradigm shift to the same degree.”
By Pascal Costanza (http://aosd.net/pipermail/discuss_aosd.net/2004-July/001004.html)

No:
“Mathematically, aspects form a second-order extension of any programming paradigm: while usual programming paradigms allow reasoning about single functions, messages and so forth by a function/message signature, AOP enables reasoning about entire sets of those entities by using pointcuts with wildcards in their signature. Thus one could view AOP as a powerful, logical extension, rather than as an independent paradigm. Friedrich Steimann, for example, has proposed such a view.”
Wikipedia(http://en.wikipedia.org/wiki/Aspect-oriented_programming)

“..In OOP you have communicating objects with encapsulated state. In FP you have the notion of encapsulated functionality and side-effect-freeness, however no explicit notion of state…that all the paradigms noted above can exists "on its own". You can use FP without OOP…AOP, however as I see it, always (correct me, if I am wrong here) makes use of a kind of "host paradigm", that provides basic expressiveness and then kind of provides a way for second-order reasoning on that "host paradigm"…”
(http://aosd.net/pipermail/discuss_aosd.net/2004-July/001003.html)
“…when moving from IP to OOP,one gains the new concept of encapsulated state together with the notion of messages. This changes the whole universe of reasoning: Instead of reasoning about loops or sequences of commands executed on a machine (IP) one now certainly talks about objects that are communicating via messages.…I see the difference in the fact that when moving from IP to OOP, we change the entities we are reasoning about (objects rather than commands) while with AOP we don't really. Of course AOP claims an aspect as the additional entity of reasoning. But can one really see an aspect as a single entity ,that is without any coupling of the outer world? Objects in OOP do so, also do functions in FP (due to side-effect-freeness), aspects however don't, since in all AOP languages you will always at some point have to conrecretize when and where your aspect synchronizes with the rest of the world…An object in OOP is fully compositional without exposing any of its subunits to the outer world. For functions in FP, the same holds. However, does that also hold for aspects?....”
(http://aosd.net/pipermail/discuss_aosd.net/2004-July/001005.html)

Two citations above By Eric Bodden

Note: FP=Functional Programming, IP=Imperative Programming.

AOSD'05 - A great conference.

In the middle of March the Annual Aspect Oriented Software Development Conference 2005(also the fourth conference) was hosted in Chicago.
Almost all the important experts, practitioners and company in this field joined this conference and it also came with many reports online and offline.
I'm really excited about this conferece for seeing the rapid development of AO. Although I can't attend this conference I read news and blogs reporting the conferece. And I have strong confidence in AOP being more and more accepted by the industry.

The Aspect-Oriented Software Association

The Aspect-Oriented Software Association is a non-profit organization whose mission is to be the primary sponsor for the annual Conference on Aspect-Oriented Software Development.
The AOSA Steering Committee members are:
Mehmet Aksit
Brian Barry
Tzilla Elrad
Bob Filman
Gregor Kiczales (chair)
Karl Lieberherr
Mira Mezini
Gail Murphy
Harold Ossher