Re: [aspectj-dev] AspectJ reflect API

[Adrian Colyer <adrian_colyer@xxxxxxxxxx>]

(b) also has one other very attractive
property whilst I think about it... it's much easier to independently build
and test the reflection API implementation (by simply @AspectJ annotating
elements).

So I think I should take a look into
@AspectJ support in the ajc front-end (which we need to do anyway in M3).

A strawman for discussion:

* If the compiler sees a code-style
declaration it will add the appropriate @AspectJ annotation (some things,
like pointcuts, currently have no member associated with them at all in
code style so that will need a bit more work, other things, like declare
soft, have no annotation at all yet)
* If the compiler sees an @AspectJ annotation,
it will generate the current weaver attributes etc. in addition (as you
say, we can think of this as an optimisation that saves the weaver some
time later on, but it also will cause us to go through e.g. the pointcut
parsing and error detection paths early on to give better feedback to the
user)

* the annotations become the minimum
standard "bytecode format" for AspectJ members - has the nice
property of letting us easily document the format simply by defining annotations
* the annotations stay at "user-level"
(so we don't put serialized pointcut AST trees in them as byte[] for example,
and anything a user sees through reflection makes sense)
* an AspectJ compiler *may* choose to
generate additional information (f.e. in class file attributes) that provide
better weaving performance / enhanced error checking / more accurate line
number reporting / whatever
* the AspectJ weaver will be able to
operate from annotations only (required for plain @AspectJ support)
* the AspectJ weaver may make use of
additional information in class files if present

and, for backwards compatibility with
aspects compiled with earlier versions of AspectJ:
* the AspectJ weaver should be able
to read in aspects compiled without annotations (by e.g. ajc v1.2.1)

-- Adrian
Adrian_Colyer@xxxxxxxxxx

Alexandre Vasseur <avasseur@xxxxxxxxx>
Sent by: aspectj-dev-bounces@xxxxxxxxxxx

19/04/2005 11:10

Please respond to
Alexandre Vasseur <avasseur@xxxxxxxxx>; Please respond to
AspectJ developer discussions <aspectj-dev@xxxxxxxxxxx>

To	AspectJ developer discussions <aspectj-dev@xxxxxxxxxxx>
cc
Subject	Re: [aspectj-dev] AspectJ reflect API

That s a very interesting debate.

We have a strong background in AW so let me sum up what we had in there.
In AW we are using ASM (the bytecode toolkit not the AJ thing) (after
having tried BCEL and Javassist). We have a fairly clean abstraction
called ClassInfo that mimic java.lang.reflect and can be created
wether using a delegation to java.lang.reflect, or using an ASM based
bytecode parser. We f.e are using the bytecode parser based version to
match the pointcut at weave time (to not trigger any class loading)
and the reflect version f.e. when we expose the pointcut matching API
to third parties, or when doing residual testing etc. This whole thing
has a lazy parsing mechanism, memory sensitive caching etc.

I don't think we really need such an abstraction there though actually
(a) or any solution *not* using real Java 5 annotations injection at
"AJC code style aspect compilation".
And I have to say that parsing the bytecode brings you back to the
common bytecode issue: "where is the bytecode " (finding it thru
class
loader resource streams usually work, but is not guaranteed, and fails
short if someone changed the bytecode at load time / runtime), once
parsed, should I cache the thing or parse it again etc etc.

So I would tend for a solution that does avoid bytecode parsing and
only trust java.lang.reflect for this need here. This means I would
tend to your (b) only, without fallback on (a) but with a path to (a)
for "prior to Java 5" :
-  use the @AJ annoations, exposing them as runtime visible, and
making sure that we ignore them during the world setting up in the
weaver for all code style aspect
- or define a replicate of those (I don't think it is so good) that
the weaver will ignore (but that means duplicate logic in the AjType,
one for code style, one for annotation style)

This indeed makes the compiled code style aspect bigger (how much) but
has the advantages of
- establishing one standard bytecode format for aspects. If you revert
the way we think, you can then see "old" AjAttribute as specific
AspectJ code style aspect enhancement (having the pointcut already
parsed etc, some compiler version info etc) but any third party can
ignore those.
- everything can be read using reflect. No extra bytecode parsing.
This should simplify the AjType API - and instead of having to deal
with bytecode parsing things, we have to deal with code style
compilation adding some Java 5 attributes (not saying it is easy..)

Some notes:
- such a "common" bytecode format is not tied to Java 5. Java
5
annotations are just a standardized bytecode attribute somehow, so we
can f.e. have ajc inject those even when not using the 1.5 mode (and
using backport for annotation style written with doclet). Then if
there is a need, the AjType API can be ported back to 1.4 using
backport (and just removing Java 5 specific syntax in the AjType API)
if someone really needs it (back to the parse bytecode issue but only
in the 1.4 mode, and it is a backport issue now..)
- I am sure some of ITD and things like privileged aspect that don't
exists in the annotation style due to java type checking enforcement
are a bit harder to modelize (since there is no @AJ annotation for
those anyway).

To sum up: I think (b) + the extra bit for the concepts that are
mising in the annotaiton style would be really nice, and help us to
use simple reflect API, while still providing a way to port the whole
to 1.4 if we really want to provide that feature.

Alex


On 4/19/05, Adrian Colyer <adrian_colyer@xxxxxxxxxx> wrote:
>  
> > Why do you want to make pointcut runtime visible while they already
>  > have a class level retention (be it code style or annotation
style) ?
>  > Don't you plan to read them back from bytecode structures
?
>  
> I should have been more precise in my comment - I don't want to create
a
> runtime dependency on aspectjweaver.jar (far too big) where all the
> attribute parsing stuff currently lives. But, to support an API like
this we
> need some way to answer the questions at runtime. Some options for
that are:
>  
> (a) parse the byte codes of the class file and pick apart the content
-
> could be made small enough I suspect, but would need a very lightweight
> class file parsing solution (not BCEL). backport175 might have some
stuff
> that's applicable here? 
> (b) use the @AspectJ annotations (placed in the .class file even when
> compiling with ajc using code style) and make them runtime visible
- has the
> advantage that it brings no extra runtime dependencies (apart from
Java 5,
> but I'm ok with that). Will increase class file size for code style
aspects
> (this will have only a marginal impact on applications). 
> (c) generate yet another runtime visible structure in the .class files
> (known "only" to AspectJ) and use that 
>  
> (d) use the @AspectJ annotations (made runtime visible) if available,
and
> fall-back on (a) otherwise 
> (e) something else? 
>  
> I think I'm leaning towards one of (a) or (b), but it needs some design
work
> and prototyping to really figure out which will be best. I think one
> important property of the solution is that folks who don't want to
use the
> reflection APIs don't pay a high price just for having the option
available
> (price being size of aspectjrt.jar, size of generated code, runtime
> performance, ...). 
>  
> -- Adrian
>  Adrian_Colyer@xxxxxxxxxx 
>  
>  
>  
>  Alexandre Vasseur <avasseur@xxxxxxxxx> 
> Sent by: aspectj-dev-bounces@xxxxxxxxxxx 
> 
> 19/04/2005 07:40 
>  
> Please respond to
>  Alexandre Vasseur <avasseur@xxxxxxxxx>; Please respond
to
> 
>  AspectJ developer discussions <aspectj-dev@xxxxxxxxxxx>
>  
>  
>  
> To AspectJ developer discussions <aspectj-dev@xxxxxxxxxxx> 
>  
> cc 
>  
> Subject Re: [aspectj-dev] AspectJ reflect API 
>  
>  
>  
>  
>  
> Why do you want to make pointcut runtime visible while they already
>  have a class level retention (be it code style or annotation
style) ?
>  Don't you plan to read them back from bytecode structures ?
>  
>  If there is some compiler work to achieve that goal by injecting
some
>  new runtime visible structures, may I raise that some complexity
of
>  this work is tied to not having a single bytecode format for
what is
>  an aspect, precisely using regular regular Java annotations
(which
>  does not mean you have to use them in the aspect source code
in code
>  style of course).
>  
>  Alex
>  
>  
>  On 4/18/05, Adrian Colyer <adrian_colyer@xxxxxxxxxx> wrote:
>  >  
>  > I just committed into the tree the outline of a solution
that I started
> work
>  > on last month (this is a *long* way from finished). Take
a look at the
>  > aspectj5rt module in CVS where you'll find the org.aspectj.lang.reflect
>  > package and org.aspectj.internal.lang.reflect. The basic
>  > notion is to introduce a new interface, AjType, which is
to AspectJ's
>  > reflection interfaces what Class is to Java's (Class is
final so we
> couldn't
>  > extend that). I've filled in the shape of the AjType interface
based to
> on
>  > the precedence set by java.lang.Class in Java 5.  (Note
that even classes
>  > get AjType equivalents in this world, since classes can
have
> pointcuts...).
>  > The interfaces for ITDs, advice, pointcuts etc. (analogous
to Method,
>  > Field,...) are not filled in yet. The size of the AjType
interface should
>  > indicate the amount of effort that needs to go into testing
this! The
>  > intended anchor into the AspectJ type world is via
>  > AjTypeSystem.getAjType(Class forClass). So you'd write
something like
> this: 
>  >  
>  > AjType aspectType = AjTypeSystem.getAjType(MyAspect.class);
>  > Pointcut[] pointcuts = aspectType.getDeclaredPointcuts();
>  > etc. 
>  >  
>  > Patches that start to flesh out the interfaces with the
stuff you need,
> and
>  > especially patches that contribute test cases would be
very welcome. We
> need
>  > to figure out how to make more of the aspect members runtime
visible so
> that
>  > the API can be implemented (pointcuts for example are not
currently -
> unless
>  > you use @AspectJ style and we decide to make the Pointcut
annotation
> runtime
>  > visible...). A lot of that work will have to happen in
ajdt.core and
>  > probably needs some committer time to get started - which
realistically
>  > means M4 timeframe I suspect. Fitting your current implementation
behind
> the
>  > interfaces and checking that they meet your needs would
be a good way to
> get
>  > started in the meantime... 
>  >  
>  > Cheers, A. 
>  >  
>  > -- Adrian
>  >  Adrian_Colyer@xxxxxxxxxx 
>  >  
>  >  
>  >  
>  >  Russell Miles <russellmiles@xxxxxxx> 
>  > Sent by: aspectj-dev-bounces@xxxxxxxxxxx 
>  > 
>  > 14/04/2005 16:21 
>  >  
>  > Please respond to
>  >  AspectJ developer discussions <aspectj-dev@xxxxxxxxxxx>
>  >  
>  >  
>  > To AspectJ developer discussions <aspectj-dev@xxxxxxxxxxx>
>  >  
>  > cc 
>  >  
>  > Subject Re: [aspectj-dev] AspectJ reflect API 
>  >  
>  >  
>  >  
>  >  
>  >  
>  > Hi Mac,
>  >  
>  >  You might find that the reflection extensions that
I've built into
> aUnit's
>  > framework (org.aspectj.aunit.framework.reflect.Aspect
> and
>  > org.aspectj.aunit.framework.reflect.Advice) might give
> you
>  > some of what you need. What it doesn't already have I'd
be happy to work
> on
>  > with you as pointcut information would be really useful
to aUnit - the
>  > problem with providing runtime reflective information on
pointcuts is
> that
>  > (as far as I can find) that information is not retained
after compile and
>  > weave.
>  >  
>  >  aUnit's source is available from www.aunit.org, follow
the SourceForge
>  > project link at the top of the page (I'm in the process
now of adding
> direct
>  > links from the homepage)
>  >  
>  >  Cheers,
>  >  
>  >  Russ
>  >  
>  >  On Thursday, April 14, 2005, at 03:18PM, Mac <mac@xxxxxxxx>
wrote:
>  >  
>  >  >Hi,
>  >  >
>  >  >I'am currently working on aspectJ5 Unit Testing
framework. I need an
>  > AspectJ
>  >  >reflect API or something like :
>  >  >              
  org.aspectj.lang.reflect.Aspect with getAdvice() and
>  > getPointcut()  methods
>  >  >and all the inherited Class features.
>  >  >
>  >  >Are you planning to provide it ? I f not, any
opinions are welcome.
>  >  >
>  >  >Thanks
>  >  >
>  >  >MAC
>  >  >_______________________________________________
>  >  >aspectj-dev mailing list
>  >  >aspectj-dev@xxxxxxxxxxx
>  >  >https://dev.eclipse.org/mailman/listinfo/aspectj-dev
>  >  >
>  >  >
>  >  _______________________________________________
>  >  aspectj-dev mailing list
>  >  aspectj-dev@xxxxxxxxxxx
>  >  https://dev.eclipse.org/mailman/listinfo/aspectj-dev
>  >  
>  >  
>  > _______________________________________________
>  > aspectj-dev mailing list
>  > aspectj-dev@xxxxxxxxxxx
>  > https://dev.eclipse.org/mailman/listinfo/aspectj-dev
>  > 
>  > 
>  >
>  _______________________________________________
>  aspectj-dev mailing list
>  aspectj-dev@xxxxxxxxxxx
>  https://dev.eclipse.org/mailman/listinfo/aspectj-dev
>  
>  
> _______________________________________________
> aspectj-dev mailing list
> aspectj-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/aspectj-dev
> 
> 
>
_______________________________________________
aspectj-dev mailing list
aspectj-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aspectj-dev