[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
RE: [aspectj-users] A question about perObjectField - instancevariables generated by ajc
|
Antti,
I have seen this behaviour before. It seems the compiler is a little
"aggressive" in the introduction of the per-object interface. Certainly for
perthis aspects the set of classes should be well known. I suggest you
raise a bug.
Matthew Webster
AOSD Project
Java Technology Centre, MP146
IBM Hursley Park, Winchester, SO21 2JN, England
Telephone: +44 196 2816139 (external) 246139 (internal)
Email: Matthew Webster/UK/IBM @ IBMGB, matthew_webster@xxxxxxxxxx
http://w3.hursley.ibm.com/~websterm/
"Antti Karanta" <antti.karanta@xxxxxxx>@eclipse.org on 30/09/2004 07:16:44
Please respond to aspectj-users@xxxxxxxxxxx
Sent by: aspectj-users-admin@xxxxxxxxxxx
To: <aspectj-users@xxxxxxxxxxx>
cc:
Subject: RE: [aspectj-users] A question about perObjectField -
instancevariables generated by ajc
> For per-object associations, this implementation I believe adds a
> field to each class that could be associated (and might calculate
> "could be" too broadly).
Ok. I think the compiler calculates it way too broadly. I would think
that for perthis - associations inserting an instance variable
referencing the aspect instance only to classes w/ matching join points
in non-static context would suffice. With pertarget the situation might
be a little trickier, though.
> As a workaround, what happens if you use within() to constrain the
> pointcut? e.g.,
>
> protected pointcut mutatorOperations() : within(CacheTestHelper+)
> && execution(void CacheTestHelper.mutatorOperation());
I tried this, but it did not change anything.
As this does not affect any functionality, I do not really need a
workaround. I was just concerned about a large number of unnecessary
instance variables being generated into a large number of classes.
Normally this does not make much difference, but even when null valued
the variables themselves take up some space and this might have a
meaningful impact on memory consumption w/ a class w/ a very large
numeber of instances (?). Also, like I said, it makes debugging just a
little harder by adding noise.
> (though you said that advice on the pointcut was not shown in
> classes affected by the perthis aspect)
No it wasn't, and the point cuts were defined so that it is (at least
to a human reader) clear that the aspect only affects the single class
it is defined in.
-Antti-
_______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/aspectj-users