[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
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
>
>
>
