Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [aspectj-users] AspectJ and memory management 
Adrian Colyer wrote:

I think we're all grappling to really understand your question. As Wes
alluded to, the terminology you use is quite confusing. 

Yeah, I've realized now that I used the "perthis" word inappropriately.


Let me try and
clarify what you are asking, and then once that is established we can let
you know the answer!



if a class A....



class A {
  void aardvark() {}
}



has a stateful "perthis" introduction X



this bit is very confusing....


Yes, ignore the "perthis" part...


which adds an implementation of the interface Y to A



but here we can attempt error recovery.....

do you mean:

interface Y {
   void whyOhWhy();
}

aspect X {
  declare parents : A implements Y;
  private String A.reason = "Ours is not to reason why"; // just to give us
some state
  public void A.whyOhWhy() { System.out.println(reason); }
}

?
That's basically it, except the implementation should not know about where it is applied (the declare part), and I need to do memory management of the whole X instance using lazy-loading. 


then I want to control how instances of X are managed


in the example above, each instance of A will have its own reason field.
There will only be one instance of X.


an invocation of Y on A must enable X to be instantiated...


this doesn't make sense to me yet (certainly not in the context of the
example above). If I change things slightly.....
  "an invocation of Y on A must enable Z to be instantiated..."

aspect Z percflow(invocationOfYOnA()) {

 pointcut invocationOfYOnA() : execution(* Y.*(..)) && target(A);

  public Z() {
    // load persistent state etc....
  }
}

you have a model where each invocation of a method on Y creates a new
instance of Z which can be GC'd after returning from the execution of Y's
method.
Right, except it's more like "..may create a new instance..". If one is already created it should be reused. And it must be GC'able any time it is not being used for an invocation. 


I guess you could actually collapse X and Z into one aspect if that is what
you are asking:

aspect X percflow(invocationOfYOnA()) {
  declare parents : A implements Y;
  private String A.reason = "Ours is not to reason why"; // just to give us
some state
  public void A.whyOhWhy() { System.out.println(reason); }

 pointcut invocationOfYOnA() : execution(* Y.*(..)) && target(A);

  public X() {
    // load persistent state etc....
  }

}

If Z can be independent it doesn't need to be an aspect.... you could
write:

aspect X  {
  declare parents : A implements Y;
  private String A.reason = "Ours is not to reason why"; // just to give us
some state
  public void A.whyOhWhy() { System.out.println(reason); }

 pointcut invocationOfYOnA() : execution(* Y.*(..)) && target(A);

 before() : invocationOfYOnA() {
   Z z = new Z();  // do whatever z does
   // presumably give someone a reference to z otherwise it will go out of
scope immediately
   // can manage lifecycle of z as you wish
 }

}

Are any of these getting close to the question you are asking?
Invocations of Y on A instances should be delegated to a memory-managed Z instance. Z should preferably be a straight implementation of Y, i.e. an ordinary JavaBean/POJO.
There are two issues, framework-wise, that has to be done: 1) add the Y interface to A 2) delegate Y invocations on A to an instance of Z, where the Z instance can be managed by factory/cache somehow. As far as I can tell, after discussing it with Wes off-list, is that 2) is not possible. 

Sorry for the confusing examples/terminology!

/Rickard

Back to the top