User-suggested New Language Features

Key Language Design Properties

Orthogonal join point model

The different kinds of join points, the different primitive pointcuts, and the different kinds of advice can be used in any combination.

This was one of the hardest parts of the design to get right, because of the "constructor must call super" rule in Java. But we finally got this in 1.0.

Pointcuts support composition and abstraction

Abelson and Sussman say that composition and abstraction are the key elements of a real language. Clearly the pointcut mechanism is the new thing in AspectJ, and so it was critical that it support composition and abstraction. The fact that someone can write:

/* define an abstraction called stateChange */
pointcut stateChange(): call(void FigureElement+.set*(*));

/* compose pointcuts to get other pointcuts */
pointcut topLevelStateChange(): stateChange() && !cflowbelow(stateChange());

is what makes it possible for people to really work with crosscutting structure and make their code more clear.

Statically type checked

The efficiency, code quality and programmer productivity arguments for this have been made elsewhere, so I won’t repeat them.

Efficient

AspectJ code is as fast as the equivalent functionality, written by hand, in a scattered and tangled way.

Simple kernel

I’ve heard some people say that AspectJ is too big and too complex. In the most important sense of simple AspectJ is simple. I can reason about any AspectJ program with a simple model. The kernel of AspectJ is simple, and the orthogonality described above means that its easy to start with just the kernel and slowly add to that.

Its pretty clear to pull out this kernel of AspectJ. I would argue that the right idea for a standard AOP API is this kernel, packaged in a way that allows building more sophisticated tools on top of it.

Supports multiple weave times

AspectJ is neutral on whether weaving happens at pre-process, compile, post-process, load, JIT or runtime. This neutrality is critical. Its why there are serious JVM experts who are already thinking about JVM support for AspectJ.

There’s more, but I think these are the most important ones. I think any functionality this group comes up with should also meet these criteria.