[news.eclipse.technology.equinox] Re: AspectJ-enabled runtime implementa

["Jeff McAffer" <jeff_mcaffer_REMOVE@xxxxxxxxxx>]

One of the things that might be interesting/possible is the use of aspects
to trigger plugin activation.  Currently activation is triggered by the
first class "load" from a plugin.  In practice, classes are often loaded
simply for verification purposes.  There is no real need to activate the
plugin as none of its code is actually being run.

What we really want is to activate on the first class initialization.
Unfortunately, Java does not provide a lifecycle event or hook for this.

Would it be feasible/reasonable to use aspects to augment the clinit()
method of every class in a plugin (or at least every API class) to make a
plugin activation check as the very first thing it does?

Jeff


"Martin Lippert" <lippert@xxxxxxx> wrote in message
news:b6cjg8$1tl$1@xxxxxxxxxxxxxxxx
> Hi,
>
> I haven't tried out so many different use cases for improving the
> Eclipse implementation using AspectJ. But one thing I used as an example
> is an aspect that logs calls any methods inside the eclipse jdt core
> package from within the control flow of a specific method. This kind of
> cflow dependent logging could be realized pretty easily via AspectJ.
>
> For example:
>
> public aspect MethodCallAspect {
>
>   pointcut methodexecutions(): execution(void *.*(..));
>   pointcut insideSomething(): cflow(execution(void
> org.eclipse.jdt.core.dom.CompilationUnit.setPackage(..))
>                              && within (org.eclipse.jdt.core..*));
>
>   before(): methodexecutions() && insideSomething() &&
> within(org.eclipse.jdt.core..*) {
>     System.out.println("execution entering " +
> thisJoinPoint.getSignature());
>   }
> }
>
> This could be written inside a separated plugin without modifing or
> recompiling the jdt core classes using the AspectJ-enabled Eclipse core
> runtime.
>
> Just one stupid example, but it might illustrate the possibilities.
>
> Best regards,
> Martin
>
>
>
>
>
> pkriens wrote:
>
> > The things I would like to do with (dynamic) AspectJ are:
> >
> > - Debugging and tracing
> > - Usage of things people should not use in a shared environment
> >     - System.out/err/in
> >     - Adding URL handlers themselves (this is a one time op)
> >     - System.exit
> >     - ...
> > - Preventing stale references (or diagnosing)
> > - Security
> > - Authorization
> >
> > Kind regards,
> >
> >     Peter Kriens
> >
> > Jeff McAffer wrote:
> >
> >> I second Peter's interest.  It would also be interesting to have some
> >> usecases to motivate this in a plugin setting.
> >>
> >> Jeff
> >>
> >> "pkriens" <Peter.Kriens@xxxxxxxx> wrote in message
> >> news:3E87FE7E.3090406@xxxxxxxxxxx
> >>
> >>> I think it is a great idea to see if this weaving could be done in
> >>> runtime. It is something I discussed at the OOPSLA 3 years ago with
the
> >>> AspectJ people but I then understood it weaving could basically only
be
> >>> done with the sources.
> >>>
> >>> I seen several applications in the OSGi world where this might be very
> >>> useful. Unfortunately, aspect oriented programming is not very well
> >>> known among embedded developers (and there are of course the size
> >>> impacts). Can you describe more in detail the API you would need from
> >>> the class loaders to make this possible? Or do you have pointers to
> >>> papers? I'd like to propose this to some of the OSGi vendors.
> >>>
> >>> Thanks, kind regards,
> >>>
> >>> Peter Kriens
> >>>
> >>> Martin Lippert wrote:
> >>>
> >>>
> >>>> Hi all,
> >>>>
> >>>> my name is Martin (Lippert) and I am new to this group. Brian Barry
> >>>> and
> >>>> Jeff (McAffer) told me that this might be the right place to talk
> >>>> about
> >>>> my ideas. So I hope you are interested in it, even if it might
> >>>> sounds a
> >>>> bit strange at first sight.
> >>>>
> >>>> During the last weeks and months I had the idea of bringing AspectJ
> >>>> and
> >>>> the Eclipse plugin model closer together by allowing people to
develop
> >>>> applications using both, aspects written in AspectJ and plugins using
> >>>> the Eclipse runtime. They would be able to write aspects in AspectJ,
> >>>> compile them with their compiler (or the respective plugin for the
> >>>> Java
> >>>> Tooling inside Eclipse) and plug them into the system as a normal
> >>>> plugin. The main motivation is that people are interested in both:
> >>>> plugins as their base runtime infrastructure and aspects to
modularize
> >>>> crosscutting concerns.
> >>>>
> >>>> I thought about load-time weaving to allow them to individually
> >>>> develop
> >>>> each plugin. Today, they can use an aspect only inside a single
> >>>> plugin,
> >>>> because the compiler weaves the aspect into the other classes. With
> >>>> load-time weaving the idea of Eclipse to encapsulate each plugin
(even
> >>>> with aspects that define cross-plugin pointcuts) would become
possible
> >>>> for aspects.
> >>>>
> >>>> So I implemented a modified version of the core plugins (boot and
> >>>> runtime) to realize this behavior and demonstrated it at the AOSD
> >>>> conference last week. The feedback was very positive and I would
> >>>> like to
> >>>> continue to improve the implementation and make it available to the
> >>>> people who are interested.
> >>>> The only thing that makes this a bit complicated is the fact that I
> >>>> had
> >>>> to implement a modified version of the base plugins. It was not
> >>>> possible
> >>>> to write a plugin that enhances the runtime in the way I want it to
> >>>> be.
> >>>>
> >>>> The main reasons for this:
> >>>> - I had to inject the weaving at class-loading time. The current
class
> >>>> loader of Eclipse do not allow me to enhance their behavior for such
> >>>> kind of things.
> >>>> - I had to add dependencies between plugins at runtime (depending on
> >>>> which aspect got woven into which class).
> >>>> - I had to add some setup code that got called after the registry is
> >>>> initialized but before the application starts.
> >>>>
> >>>> And this is exactly the point where it might be interesting for this
> >>>> project. These are exactly the points where I would love to make the
> >>>> runtime more flexible. This might seem a bit strange (especially the
> >>>> load-time modifications of classes), but the load-time weaving of
> >>>> aspects opens a totally new world of possibilities for aspects and
> >>>> plugins used together.
> >>>>
> >>>> So I am highly interested in hearing your opinions on that. I can
also
> >>>> provide more technical details of the possible enhancements to the
> >>>> runtime. I would also love to contribute some code for this kind of
> >>>> modifications, if possible. What do you think?
> >>>>
> >>>> Best regards,
> >>>> Martin Lippert
> >>>>
> >>>>
> >>>> ---
> >>>> Martin Lippert
> >>>> email: lippert@xxxxxxx
> >>>>
> >>>>
> >>>>
> >>
> >>
> >
>