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

[Martin Lippert <lippert@xxxxxxx>]

Hi Jeff,

> 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?
Sounds interesting. Using AspectJ to write such an aspect would mean to 
do something like to following:

public aspect MyAspect {

 pointcut mycut(): staticinitialization(SomeTypeOrWildcardForEveryType);

 before(): mycut() {
   ... do something ... for example activate the plugin ...
 }

}


-Martin

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