Re: Are Limitations in AspectJ 1.1 satisfied with1.5?

Ajc 1.1 used binary weaving: the change occurred after ajc 1.0

It is true that the AspectJ team deliberately decided to not allow access to
local variables in pointcuts on the grounds that it wouldn't be stable.

I will testify that the Glassbox open source project (see Glassbox.com) is
using AspectJ successfully to measure performance on and report problems
with black box applications. Most performance management tools and profilers
don't go deeper than method and constructor execution. I believe that is
sufficient depth for measuring performance.

In my view, the major use case where AspectJ isn't fine-grained enough is
measuring code coverage for tests. I believe the right direction there is to
be able to write pointcuts that match branching without picking out line
numbers or variable names. That might also be of some value for really
fine-grained spotlighting when profiling too. I believe that the EOS
research project offers this kind of more fine grained yet anonymous
pointcut although I haven't looked it in a while... 

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf
Of Eric Bodden
Sent: Tuesday, September 05, 2006 9:20 AM
To: Fabiano Ricci
Cc: [email protected]
Subject: Re: [aosd-discuss] Are Limitations in AspectJ 1.1 satisfied
with1.5?

> 
> 1) It doesn't provide a full support to access variables in the target
> program.
>     A pointcut can create a reference to all variables  in a joinpoint.
> Possible variables are: this, target. variables passed as parameters to
> the actual function in object and the returning value of the method. If
> we want catch other variables we must change the Source Code ( not
> available in black-box application ) and include this variables in that
> jointpoint

This has not changed in AspectJ, but is available via the "let" pointcut,
which lets you bind expressions in the form of let(x,someExpr()) and is
available in the "EAJ" extension to AspectJ (www.aspectbench.org).
 
> 2) If we want to access an object at runtime, we need to know the type
> of that object. So if we don't know the source code we can't access to
> that object. There is a manner to avoid this?

I don't understand that statement. Of course you can access objects which
were created in code which you don't have the source code for. Maybe they
are referring to the fact that ajc 1.1 used source code translation. So yes,
that should be solved.

> This two issues make very difficult create an aspect that automatically
> profiling black-box applications

Many more subtle problems remain, however that's another topic.

Eric

--
Eric Bodden
Sable Research Group, McGill University
Montréal, Québec, Canada




_______________________________________________
discuss mailing list    -    [email protected]

To unsubscribe and change options, go to:
http://aosd.net/mailman/listinfo/discuss_aosd.net

Check out the AOSD.net Wiki: http://aosd.net/wiki


_______________________________________________
discuss mailing list    -    [email protected]

To unsubscribe and change options, go to:
http://aosd.net/mailman/listinfo/discuss_aosd.net

Check out the AOSD.net Wiki: http://aosd.net/wiki