Bug 108099 - Binary weaving ITDs (including generic ones) #1
Summary: Binary weaving ITDs (including generic ones) #1
Status: RESOLVED FIXED
Alias: None
Product: AspectJ
Classification: Tools
Component: Compiler (show other bugs)
Version: 1.5.0M3   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: 1.5.0 M4   Edit
Assignee: Andrew Clement CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-08-26 07:20 EDT by Andrew Clement CLA
Modified: 2005-10-03 13:02 EDT (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Andrew Clement CLA 2005-08-26 07:20:13 EDT
I'm just not sure if this works right now... I started writing a few testcases,
I got unstuck - but not for the reason I thought I would but for something much
more fundamental.  You can see the problem I hit with the testcase

public void testBinaryWeavingITDs2() {runTest("binary weaving ITDs - 2");}

in GenericsTests which is currently commented out, its a very simple test run:

step1) It weaves a BaseClass with an aspect A1 into an output jar (-1.5,
-Xreweavable) - A1 adds a field List<String> to BaseClass.

step2) it then uses that output jar as input to another weave, this time with
aspect A2 - A2 is defined to add another field called List<String> to BaseClass.

This was my first simple scenario - the second step verifies the binary weaving
of A1 and BaseClass together.

but it just doesnt work.

The first compile step is OK, the second compile step fails - you get an error
from A2 saying it cant find the 2nd list it introduced onto the base type.

Digging a little, I find this strange circumstance:

Look in AjLookupEnvironment.weaveInterTypeDeclarations(SourceTypeBinding
sourceType, Collection typeMungers, 
			Collection declareParents, Collection declareAnnotationOnTypes, boolean
skipInners) 

this method is passed a set of type mungers. In the case of the 2nd compile,
this includes the one that adds the second field, 'list2':

[(EclipseTypeMunger ResolvedTypeMunger(Field, java.util.List<N> BaseClass.list2))]

the first part of the method then says:
- is there a weaverstate info around?  When weaveIntertypeDeclarations is
running for BaseClass the answer to this question is YES (we built things
reweavable).  The if() block then retrieves type mungers from the state info,
applies them to the target type *AND RETURNS* - it doesnt continue to apply the
set it was passed?!?!?  So the list2 never makes it onto the type.
I commented out the return to enable it to proceed and apply the type mungers it
was passed as well, and that causes this test to work but others in the suite to
fail :(

So I'm not quite sure whats wrong there, but something is... and making
reweavable the default will add to the confusion when we decide to do that...
Comment 1 Adrian Colyer CLA 2005-09-01 09:52:26 EDT
for M4
Comment 2 Andrew Clement CLA 2005-10-03 10:10:48 EDT
Fix checked in.  Waiting on build before closing - see related bug pr83717.
Comment 3 Andrew Clement CLA 2005-10-03 13:02:56 EDT
fix available, woooo