Re: [aspectj-dev] weaving information via messages

[Martin Lippert <lippert@xxxxxxx>]

Hi Wes,

> This would be interesting information, and a good feature request to
> put in the bug database.  There's a lot of similar information that
> clients might like. Before we go down the road of adding message
> types and instrumenting the compiler in various (scattered?) places,
> we should consider whether that's where this feature belongs.

Already added to the bug database:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=36747

> Normally, we try to use AJDE for API clients of compiler to insulate
> the compiler code from extraneous concerns, so perhaps your feature
> request should be addressed to AJDE. Normally we think of ADJE as
> supporting IDE's, but perhaps it should also be used for non-IDE
> clients of static structure.

> One question is whether AJDE could work well here with the process of
> load-time weaving. If load-time weaving is one long compile process,
> handling each new set of bytecode in turn, it never "completes", per
> se:
>
> - all aspects loaded - load class - get bytecode - weave bytecode -
> load any required classes - for already-defined classes, get from
> classloader - for undefined classes, do {nested} load/weave - define
> class ...
>
> I'm not sure if AJDE is set up to provide in-process signals or
> surface a partial structure model before a compile has completed.  If
> it is, we should use that.  If not, we should consider whether that's
> where we should be putting these efforts.

Good point. I already thought that the AJDE people might have to solve a
similar problem: find out, which aspect is woven into which class. How 
do they generate that information?

> There are other alternatives.  The bytecode weaver could annotate the
> woven class with attributes listing aspects which affect it, which
> could be pulled when weaving was completed from the live model and
> could be available for other static analysis tools aware of the
> attribute (We could surface an API for a decompiler which would
> understand any custom attributes we put in the .class files.)  That
> in effect creates a data interface rather than an API interface.
>
> If we do put this in the compiler and the signals are scattered, then
> this is a good candidate for an aspect to provide the in-process
> messages, after we commit to building AspectJ with AspectJ.

Cool. Do you really plan to develop AspectJ with AspectJ in the near future?

> Finally, I should say that before we add features to support
> load-time weaving, I'd like to have a weaving class loader
> implemented with tests and available in the download for people to
> use.  I appreciate your contribution[1], but we haven't quite
> finished this process for (and in light of) 1.1.

Yes, good point, too. What do you think needs to be done for the weaving 
class loader in addition to my contribution (apart from some good tests)?
(Maybe we could discuss this via the bug database?)

Best regards,
Martin





> Thanks for bringing this up. Wes
>
> [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=31460
>
> Martin Lippert wrote:
>
> > Hi,
> >
> > for the dynamic weaving functionality that I implemented for the
> > Eclipse runtime I need to know which aspect got woven into which
> > class. Therefore it would be good if the weaver would generate
> > messages during the bytecode weaving. Those specialized messages
> > could contain information for the aspect and the class. I
> > implemented a special subclass of Message and added the creation of
> >  the message to the BcelAdvice class (a simple test case for this
> > as well). I used the Message.INFO kind for this to not modify the
> > IMessage interface. It might be better to have a special
> > IMessage.Kind for that, something like "WOVEN". What do you think
> > about this kind of information mechanism?
> >
> > In addition to that I believe there are more places (in addition to
> >  BcelAdvice.implementOn(..)) where this kind of information should
> > be generated, but I do not know exactly, where they are. Do you
> > have any idea where I should put this message creation, too?
> >
> > Best regards, Martin
> >
> > _______________________________________________ aspectj-dev mailing
> > list aspectj-dev@xxxxxxxxxxx 
> > http://dev.eclipse.org/mailman/listinfo/aspectj-dev
>
> _______________________________________________ aspectj-dev mailing
> list aspectj-dev@xxxxxxxxxxx 
> http://dev.eclipse.org/mailman/listinfo/aspectj-dev