Re: [aspectj-users] latest incarnation of load-time weaving

["Wes Isberg" <wes@xxxxxxxxxxxxxx>]

Hi Alex -

I agree that many users, current and new, will use load-time weaving 
for the first time in AspectJ 5, because it will be as easy to use 
as AspectWerkz, and will not involve managing class loaders.  What
I was saying is that the part of load-time weaving that concerns
some people, bytecode weaving, has been proven over a number of
AspectJ releases.  People considering LTW should be confident that
the quality of the LTW support in AspectJ 5 is not just alpha or beta 
or even first-release; it combines the technologies of AspectJ 
and AspectWerkz that have been proven over a number of releases.

I'm not sure what you're suggesting with 

> the way to configure a system and package aspects as
> modules (the plural matters here) that can be deployed there in a
> consistent way with precisely defined rules

since the prior implementation allowed aspects to be packaged
as modules deployable in a consistent way, etc.  It was just 
harder to do, and to get it right, so (as you suggest) it's possible
that not very many people did it for complex applications.

The difference is like that between, on the one hand, "doing" AOP 
in Java by using your own reflection/writing your own weaver and,
on the other hand, using the AspectJ language: with the new LTW support, 
users will be able to just specify what should happen rather than 
implement it themselves, and your implementation will take care 
of doing the right thing.  In this sense, it matters, but it's not
determinative, what the research community thinks is LTW.  Researchers 
have a responsibility to be honest and forthright, but their technologies
need only be a proof-of-concept.  But with so many users we have a 
responsibility to really get the usability and robustness right.
We can't waste people's time with stuff that doesn't work or is
hard to use; when we say it's ready, it must really be ready. 
We characterized the prior LTW support in AspectJ as, "it's possible
and here's how you'd do it" - i.e., with full disclosure that the
user would be doing some of the engineering.

In this light, bringing the AspectWerkz experience of load-time weaving 
into AspectJ does mean it's "new in AspectJ 5" for most users.
More importantly, I believe that by making it so easy to configure and
deploy library aspects, the AspectJ 5 LTW support will bring many
new users into the AOP community.

Wes

> ------------Original Message------------
> From: Alexandre Vasseur <avasseur@xxxxxxxxx>
> To: "Wes Isberg" <wes@xxxxxxxxxxxxxx>, aspectj-users@xxxxxxxxxxx
> Date: Thu, May-19-2005 4:34 AM
> Subject: Re: [aspectj-users] latest incarnation of load-time weaving
>
> I would be interested in knowing
> - who is using the "aj" script 
> - who is using the WeavingClassLoader
> - who is using implementation of concrete integration like
> weblogic-aspect (who else has provided an implementation ?)
> 
> and in which context: to add weaving capabilities to an existing
> environment, or just to try things with an HelloWorld or see if your
> development cycles could be improved etc.
> 
> This would be a good information to figure how the current users will
> use the new load time weaving in AspectJ 5.
> I don't think former AspectWerkz user experience will change or will
> appear as new in this area but I definitely think current AspectJ user
> experience will apear as new.
> 
> If we define load time weaving as weaving classes as they gets loaded,
> yes it is not new, and it is not even AOPish. If we - as AOP folks -
> define it as the way to configure a system and package aspects as
> modules (the plural matters here) that can be deployed there in a
> consistent way with precisely defined rules, then it will definitely
> be new in AspectJ 5.
> What is the AOP research community definition of "load time weaving" -
> any one knows ?
> 
> Alex
> 
> On 5/19/05, Wes Isberg <wes@xxxxxxxxxxxxxx> wrote:
> > This is to correct the misperception floating around that load-time
> > weaving support in AspectJ is new with AspectJ 5.  The usability and
> > features are definitely growing, but the core technology has been in
> > use for some time.
> > 
> > In AspectJ 1.1, we changed to bytecode weaving and made the weaver
> > independent of the compiler.  At that point, some enterprising 
> programmers
> > used the weaver directly in their class-loading implementations to 
> weave
> > bytecode as it was loaded.
> > 
> > In AspectJ 1.2, we provided a default implementation, the
> > WeavingClassLoader.
> > 
> > The Java 1.4 VM's provided a hook for replacing the system class
> > loader, so you can deploy from the command line.  This made it
> > possible to write a script launcher, bin/aj{.bat}.
> > 
> > The Java 5 VM's support an API for a bytecode munger directly,
> > avoiding the need for a custom class loader altogether.
> > 
> > AspectJ 5 will allow you to list aspects explicitly and define 
> concrete
> > aspects using XML configuration, with usability much like 
> AspectWerkz.
> > 
> > Altogether, this should make it possible to deploy aspect libraries
> > which can be configured by users unfamiliar with AOP or AspectJ, and
> > should make it easier to deploy in container-based environments.
> > Because users no longer need develop their own class loaders, I
> > expect loadtime weaving to be more robust that it is now.  As for
> > new issues, I suspect that we'll be mostly sorting out the language
> > in aop.xml and working out how to support users who simply configure
> > aspects.
> > 
> > So if you normally would wait a few releases as the bugs are driven
> > out of a new technology, consider trying load-time weaving in the
> > next milestone release, if what you're trying to do is supported by
> > aop.xml.  If it works at all, it should work as well as using
> > build-time weaving.
> > 
> > Wes
> > 
> > _______________________________________________
> > aspectj-users mailing list
> > aspectj-users@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/aspectj-users
> >
>