[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [aspectj-dev] Re: [Bug 55107] add removeLibraryAspect method to weaver


I have moved the discussion to aspectj-dev as the questions are broader
than the suggested weaver enhancement.

But I disagree in the run-time weaving scenario.

When you say "run-time" what do you mean. The proposed LTW design for JDK 1.4 does not support hot-code-replace as there is no interception point. Developers should use normal compile-time weaving with incremental compilation and Eclipse should automatically submit all the changed classes and aspects to the JVM being debugged. In 1.5 the java.lang.instrument API provides the opportunity to reweave HRC'd classes. However HCR for aspects is a different proposition which I haven't thought about yet!

Two thoughts that I have in mind:

I played with hot code replacement (for various reasons) and there is
one difficulty that I see when talking about runtime weaving for AspectJ
  done via HCR: Current VMs do not support "real" changes to the classes
that are replaced (doesn't mapper if it is via the debug option of JDK
1.4 or the instrument package of JDK 1.5). Most VMs support only changes
to the implementation of methods. You are not allowed to add or remove
methods or static things (what you would need for AspectJ, I think).
Only few VMs support new or removed methods for redefined classes. If
you start to add fields to a class, I do not know of any VM that
supports this kind of change to a class (even though the theory for this
feature is well-known). Therefore I skipped any experiments to do
run-time weaving for AspectJ using HCR. But I would be happy to hear if
someone else got different results.

What I do instead to play with "run-time-like" weaving for AspectJ is to
enhance my AspectJ-enabled Eclipse Runtime to handle dynamic plugin
behavior correctly. In my current implementation the runtime uses
load-time weaving for plugins to weave existing aspects into the system.
Plugins can define new aspects via an extension point of my enhanced
runtime. When you think about dynamic plugins (as the are supported by
the new OSGi-based runtime of Eclipse 3.0) you could think of plugins
being installed and uninstalled at runtime. The Eclipse runtime handles
this correctly. So what I am trying is to let my enhanced runtime react
to those install/uninstall events correctly. This way you can
install/uninstall aspects at runtime without closing the application and
have a real "unweaving" at runtime. Sounds a bit tricky and I am not
sure whether this will work for all possibilities of the AspectJ
language but let me try. ;-)

Therefore I remove aspects from an existing weaver.

BTW 1: How does the incremental compilation deal with deleted aspects?

My understanding is that when an aspect is added, modified or removed everything is rewoven thereby preserving the invariant.

Ah, okay. No magic here. ;-)

BTW 2: You can achieve the same effect (that the removeLibraryAspect
would provide) via World.getCrosscuttingMembersSet().deleteAspect(..).

That method is only called once during BcelWeaving construction. Mutation is not supported.

But it seems to work. ;-) Okay, haven't tried too many things with this stuff. Are there any obvious things were the removal could cause problems with the internal weaver structures?


Matthew Webster AOSD Project Java Technology Centre, MP146 IBM Hursley Park, Winchester, SO21 2JN, England Telephone: +44 196 2816139 (external) 246139 (internal) Email: Matthew Webster/UK/IBM @ IBMGB, matthew_webster@xxxxxxxxxx http://w3.hursley.ibm.com/~websterm/

bugzilla-daemon@xxxxxxxxxxx on 20/03/2004 14:14:12

To:    Matthew Webster/UK/IBM@IBMGB
Subject:    [Bug 55107] add removeLibraryAspect method to weaver


------- Additional Comments From lippert@xxxxxxx  2004-03-20 09:14 -------
I see this from a different point of view. I agree to your objection
the weaving class loader and the typical load-time weaving scenario
described in
bug #31460. Therefore you should not remove any aspects while the load-time
weaving class loader is active.
But I disagree in the run-time weaving scenario. Of course you have to be
careful with already loaded classes, reloading, and so on. But if you take
of the different situations and handle then in the right way, the
removeLibraryAspect method would just prevent you from creating a new

BTW 1: How does the incremental compilation deal with deleted aspects?

BTW 2: You can achieve the same effect (that the removeLibraryAspect method
would provide) via World.getCrosscuttingMembersSet().deleteAspect(..).

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

aspectj-dev mailing list

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature