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

["Jeff McAffer" <jeff_mcaffer_REMOVE@xxxxxxxxxx>]

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