When turned on using any kind of compilation/weaving mode (compiling with ajc, within Eclipse AJDT, doing bynary weaving, or using loadtime weaving), each weaved class keeps track of

• the aspects that are affecting it
• its state before the weaving happened (ie its bytecode without aspects)

This option is very handy when you plan to weave more than once your application (because f.e. this is a library that you distribute), and when you want to make sure everyone will be able to add some more aspects in there.
Actually, discussions are taking place if this should be the default.

An interesting consequence is that it is fairly easy to implement an opt-out AOP engine that simply restores the state prior to weaving, and thus kicks out all the aspects from the application !
There are of course realistic use-cases for it :

• sanity check if production is very scared about use of AspectJ, knowing that the developpers team is using it for their own needs (declare error / warning f.e. and tracing in QA stage etc)
• obtain some more info about which aspect is in, and is affecting the application, to increase the trust everyone gets in using the technology
• introspect some third parties libraries and see if they actually use aspects
• add some more reporting features on the go, to be able to have at any time the list of aspects that are in the system f.e. thru some sort of web console
• enforcing that some key section of the system are not allowed to be advised by anything, or only by some sort of well know and certified aspect(s)

A small amout of code is required for it, the trick is mainly to add another Java 5 agent or loadtime weaver that will check for this reweavable state and do the reporting.
This is actually very easy to do when using f.e. AspectWerkz-core as the backend to hook this one in and have it work as well on Java 1.3, and using ASM for the bytecode details.

Here is a sample output (I am using AspectJ loadtime weaving to do the weaving first, but that could be done using post compilation with AJC, or compilation from within Eclispe AJDT etc)

// in this sample, start the app with AspectJ loadtime weaving (could have been compiled with ajc instead)
// and pipe with the UndoAspectJ opt-out engine using the AspectWerkz core
// as a backend
#java -javaagent:aspectjweaver.jar -Daj5.def=test/aop.xml
       -javaagent:aspectwerkz-jdk5-2.0.jar
       -Daspectwerkz.classloader.preprocessor=
          org.aspectj.ext.undoaspectj.ClassPreProcessor
       test.undoaspectj.Sample

weaveinfo Type 'test.undoaspectj.Sample' (Sample.java:28) advised by
   around advice from 'test.undoaspectj.Sample$TestAspect' (Sample.java)

// here is the opt-out message
UndoAspectJ - test/undoaspectj/Sample was affected by 
	test.undoaspectj.Sample$TestAspect

// execution without any aspect takes place:
Sample.target

// without the opt-out we would see the aspect executing:

weaveinfo Type 'test.undoaspectj.Sample' (Sample.java:28) advised by
   around advice from 'test.undoaspectj.Sample$TestAspect' (Sample.java)

// execution with aspect takes place:
Sample$TestAspect.around
Sample.target

Though the first idea is quite odd and counter productive, this illustrates that ones could easily implement a security layer on top of AspectJ without even going deep in the AspectJ code base, to enforce security constraints about the use of AOP in the system and in the deployments at large.

So is opt-out AOP good or evil ?