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.
Wes
------------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 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
_______________________________________________
aspectj-dev mailing list aspectj-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/aspectj-dev
|