The Java approach to Object-Oriented Design by Contract can be extended and applied to Aspect-Oriented Software. For doing so, we need to address how current Object-Oriented Design by Contract can be modified to tackle aspect advising, as well as to actually extend the Design by Contract approach for aspect modules. Our approach is general enough to be applied to Java Aspect-Oriented extensions such as AspectJ, CaesarJ, and FuseJ.

Language design focusing on a single goal like, e.g., obliviousness, may easily interfere with other desirable properties. As proposed by Leavens and Clifton, a language engineering approach should apply a number of continuous scales for assessing a language's support for the multiple concerns to be considered. This leads to languages that implement a compromise between different concerns in order to balance benefits and drawbacks. In order for such a compromise to fit for all software development projects language engineers would need to be omniscient. Therefore, I propose a more modest approach, where language engineers only set the stage for negotiations between the actual stakeholder of development. Using encapsulation as an example concern, I sketch the concept of "gradual encapsulation" where each project at each point in time may choose the appropriate balance between safety and flexibility.

Groovy AOP is a general-purpose AOP system for Groovy, a JVM-based dynamic language. Groovy AOP provides a hybrid dynamic AOP implementation based on both meta-programming and bytecode transformation. It implements the pointcut-advice model of AspectJ. Based on Groovy syntax, Groovy AOP introduces a domain-specific language for declaration of aspects, pointcut expressions, and advice. At runtime, it utilises the dynamic compilation capability of the JVM to convert advice codes woven by meta-programming into bytecodes. Preliminary results show that this dynamic weaving technique preserves the nature of a dynamic language, while reducing runtime overheads.

Framework-based application development requires applications to be implemented according to rules, recipes and conventions that are documented or assumed by the framework's Application Programming Interface (API), thereby giving rise to systematic usage patterns. While such usage patterns can be captured cleanly using conventional aspects, their variations, which arise in exceptional conditions, typically cannot be. In this position paper, we propose materializable aspects as a solution to this problem. A materializable aspect behaves as a normal aspect for default joinpoints, but for exceptional joinpoints, it turns into a program transformation and analysis mechanism, with the IDE transforming the advice in-place and allowing the application developer to modify the materialized advice within the semantics of the aspect. We demonstrate the need for materializable aspects through a preliminary study of open-source SWT-based applications and describe our initial implementation of materializable aspects in Eclipse.

The goal of the SPLAT workshop is to investigate insofar the software engineering '-ilities' are being addressed by aspect-oriented programming. This paper looks closer at one of these properties (composability of aspects), which is closely coupled to evolvability, comprehensibility and modularity. It discusses problems that can arise when composing (independently developed) aspects, investigates some existing approaches that deal with composing aspects, and their advantages and disadvantages. It then outlines our own aspect composition model, which is discussed in more detail in a submission to another workshop.

In the past, repositories of examples of the well-known Gang-of-Four design patterns brought insights on the potential contributions of aspect-oriented programming, as well as providing a suitable case study for subsequent research. In this paper, we present the first results of an ongoing effort to bring these advantages to a broader range of aspect-oriented languages. We present several implementations in CaesarJ of seven Gang-of-Four patterns. A short analysis follows, in which a comparison is made with AspectJ.