[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [aspectj-dev] AspectJ reflect API

I like this approach a lot, but recommend we encourage people not to rely on preliminary engineering.
One question about 'the annotations become the minimum standard "bytecode format" for AspectJ members': I am very interested in getting to a standard bytecode format, but I'd like to avoid having us sign up to one until we're fairly sure we can support it.  One concern is whether *all* (possible) AspectJ language forms can be expressed as annotations.  In a rudimentary way they can, but if we canonicalize the rudimentary way, we might be constraining the bytecode form unduly or, conversely, constraining the language unnecessarily.  (For example, if we commit to 'the annotations stay at "user-level"' and users start relying on that, then we will probably miss some optimization opportunities for weaving or tool support, or entangle ourselves in dual-formats, canonical/public and private/optimized as suggested by the "may" language below (an issue raised initially by Alex).  We could introduce indirection to the API to manage the deltas for clients, but that vitiates the benefit of using standard reflection/annotations.)
So for this period when we integrate (AspectWerkz) code- and annotation- style, let's allow ourselves some 1.5.x releases to work out the bytecode form before standardizing it.  (Of course we should always try to support upwards binary compatibility.)
Similarly, I would flag runtime reflective access as "experimental and subject to removal."  This has the potential to be very complex but the use cases (which are, what, testing? tools? Spring?) are not as critical to AspectJ's success as, say, a steady increase in performance might be.  By that token, we might leave it in aspectj5rt and backport to 1.3+ after we've sorted it out, and segregate any documentation as such.
I view Java 5 and the @AspectJ/Aspectwerkz integration as a driver for the 1.5 release, but would "drop" reflection and bytecode form for schedule reasons.  We can use that engineering to do the integration for the limited paths of compiling and weaving without signing up to the larger issues of supporting those forms.  Conversely, if we get a fairly robust set of tests defining the capabilities of those features (from the community?), I'd be more confident with our signing up for them.
------------Original Message------------
From: Adrian Colyer <adrian_colyer@xxxxxxxxxx>
To: "Alexandre Vasseur" <avasseur@xxxxxxxxx>, "AspectJ developer discussions" <aspectj-dev@xxxxxxxxxxx>
Date: Tue, Apr-19-2005 4:17 AM
Subject: Re: [aspectj-dev] AspectJ reflect API

(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

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>

AspectJ developer discussions <aspectj-dev@xxxxxxxxxxx>
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.


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 mailing list