Community
Participate
Working Groups
See Bug 148880 ([ltw] loadtime weaving is not inlining around advice) for discussion. Offline all aspects are always woven upfront before other types. However there are consequences associated with doing this for LTW where pre-empting activities that are usually performed lazily can have unwanted side-effects: 1. We may never define (as opposed to register and resolve) and therefore weave an aspect either because it doesn’t match anything or woven join points are never reached. 2. An aspect may have a large number of dependencies that must be resolved for weaving to take place which will impact weaver initialization. We _could_ have an LTW option e.g. –XweaveAllAspects to make this enhanced behaviour optional but I am reluctant to clutter the public interface to solve a problem in a single system i.e. WebSphere.
I’m not sure we can do this for that same reason that we have problems implementing Bug 133770 “[ltw] Problem with Declare Parents and Call Munger in Load-Time Weaving”. As a weaver just because I can see 2 aspects that will weave the classes that my ClassLoader defines does not mean that the aspects will necessarily weave each other. The only thing we can be sure of is that an aspect can weave itself. Some examples: 1. Loader1(Class, Aspect1, Aspect2): the aspects weave each other 2. Loader1(Class) -> Loader2(Aspect1, Aspect2): same as 1. above 3. Loader1(Class) -> Loader2(Aspect1) -> Loader3(Aspect2): Aspect2 _may_ weave Aspect1 but not vice versa! There is also another problem with the solution to Bug 119657 “IllegalAccessError with around advice on interface method call”. If we inherit a concrete aspect we will use the unwoven byte-code. However we will never weave it and hence never inline any around advice! This is because when we define aspects during weaver initialization we have no idea who has or will actually define them as types. We only have the byte-code.
Won't make 1.5.3.
unsetting the target field which is currently set for something already released
