Re: [aspectj-users] Can I do any of these 3 things with aspectJ

[Jim Hugunin <lists@xxxxxxxxxxx>]

BTW - I think you'll have better luck getting your questions answered if 
you ask them one at a time instead of in batches.  In that spirit, 
here's my answer to "#1":

Tarun wrote:
>>Question 1 : If, my requirement is to return a different instance (say
>>instantiating overloaded constructor) of an object whose default
>>constructor is called. Can I do that with aspectJ. The limitation is that
>>I do not want to use call() pointcut, (as this needs the caller's to be
>>included in weaving though source or binary and I do not have control
>>over the usages of my framework).

It is not possible to change the object that is returned by a 
constructor without access to the code that is calling the constructor. 
 This limitation is caused by the design of the Java bytecode and JVM, 
and there's no way around this restriction short of using a modified 
JVM.  Here's the bytecode for a simple call to a constructor, "new C()":

  new C
  dup
  invokespecial void C.<init>()

The new object is created by a special 'new' bytecode, then it is 
duplicated to keep a copy on the stack, and then the constructor is 
called to initialize the object.  Notice that the constructor itself 
returns void.  The only way to change the object returned by this 
constructor call is to have access to the call-site (as shown above), 
where after the call to the constructor a different object can be put on 
the stack if desired.

Ron Bodkin wrote:
> Re: #1, I believe the only way to change the constructed object is
> with call advice. This is a case where AspectJ-1.0's callee-side
> support for call advice allowed a capability that AspectJ-1.1 can't
> achieve :-( One way to achieve the same effect would be to use factory
> methods in your framework instead of default constructors, which you
> can then advise.

This is not a change from ajc-1.0.  The callee-side implementation of 
call join points in 1.0 would silently not be used in this case because 
it was impossible for the implementation to change the returned object. 
 This kind of surprising (and often silent) implementation restriction 
was a big part of why we removed the callee-side implementation from 
ajc-1.1.  Any time that you NEED some special property that is only 
available at a call joinpoint, and not at the corresponding execution 
joinpoint, then you also NEED access to the call-site at compile-time, 
load-time or weave-time.

-Jim