[aspectj-users] Solution: Thoughts about an AspectJ classloader

["R. Dale Asberry" <lists@xxxxxxxxxxxxxxx>]

I've mostly solved the issue with the nulls being replaced by NullObjects.

The solution in the case of interfaces is to use a dynamic proxy.  When a
program attempts to use the NullProxy, the invoke() method throws a
NullPointerException.  The exception contains the stack trace from when the
NullProxy was created and uses it as the initCause.

In the case of objects, an aspect creates a new default object using
Class.newInstance().  The aspect then creates an exception containing the
initCause and stores it in a hash map with the new object as the key.  When
the object gets invoked, the aspect determines if it is a stored NullObject.
If it is, a NullPointerException is thrown using the stored exception's
stack trace as the initCause.

In both cases, my code "massages" the stack trace by removing the
aspect-related elements which leaves a very clean description of where the
NullObject was assigned.

Unfortunately, I implemented this using two widely matching pointcuts:
call(* *.*(..)) and set(* *.*) and used around() advice to detect and wrap
the null assignments.  Another issue is that this won't work with objects
that don't have a default constructor.  The last issue is that the hashmap
could grow quite large when variables are assigned a reference to another
object.

To see my solution:
<a
href="http://daleasberry.com/code_library/aspectj/project_nullobject/test/Ma
in.java">Main.java</a>
<a
href="http://daleasberry.com/code_library/aspectj/project_nullobject/test/Nu
llObjectAspect.aj">NullObjectAspect.aj</a>
<a
href="http://daleasberry.com/code_library/aspectj/project_nullobject/test/Nu
llProxy.java">NullProxy.java</a>
or all of the above jarred-up:
<a
href="http://daleasberry.com/code_library/aspectj/project_nullobject/nullobj
ect.jar">nullobject.jar</a>