Nanning - Nanning Aspects

Nanning Aspects has the following features:

An aspected object consists of a set of mixins. Every mixin is an interface, a target-object and a set of interceptors (advises on method-calls), these interceptors intercept calls on the interface on it's way to the target.
An aspected object is used by creating a Proxy with the Reflection API. This proxy will implement all the interfaces of all the mixins by invoking all the interceptors for the called method and finally calling the proper implementation of the target object.
Attributes (as Javadoc-like tags in the source code or as an xml-document with the same name as the class) can also be added to classes, fields and methods. These attributes are accesible at runtime.
Inherited interfaces will call correct target. If several aspects implement same interface the first one will take precedence. The target of the aspect-class will always take precedence before the rest.
An XML-config format that's actually a Jelly-script .
Method-selectors that selects what methods an interceptor should intercept.
Super-simple implementation. Really! Anybody can do it!

Nanning Aspects has the following restrictions

You can only advise on method-call pointcuts which is far from the power that for example AspectJ offers. On the other hand compared to the complexity of AspectJ Nanning is much, much simpler. In reality many of the benefits of AOP can be reached with this simple construct. At the moment there is also some experimental support for intercepting object-instantiation.
All your objects need to have interface and implementation separated, that is all public methods (accessible to clients) needs to be placed in an interface which is implemented by the actual class. In contrast to EJB your implementation must implement the interface, which also forces your implementation to stay in sync with your interface. (This is actually good, because the java-compiler will choke if they're out of sync before your code even hits unit-tests.)
You'll get indeterministic effects if your interface has a method with same name as a method of another interface for the aspected object. (Currently considering disallowing this altogether.)

Nanning Aspects do not have these features (yet?):

Functionality to build aspected objects via the same semantics as AspectJ. That is via join-points, pointcuts and advises. It is being considered.
Because of this an aspect isn't completely modular, for example the state introduced to an aspected object isn't located in the same module as the interceptor that will act on that state. Consider for example an Access Control List-aspect. The fields containing the access control entries will be in a mixin while the code that actually enforces the access control will be in an interceptor. If Nanning supported more AspectJ-level semantics this problem could be remedied and both mixins and interceptors along with the pointcuts describing where these should be advised could be tied together via an aspect (and even placed in the same class).
A mega-cool logo.
A set of interceptors that will supersede EJB forever!