Comment 1 Andrew Clement 2005-01-26 11:05:57 EST

The attribute not being understood in the error message is WeaverVersion - this
attribute was added right before shipment of AspectJ 1.2.1.  An AspectJ 1.2.1 or
above weaver will understand them.  It sounds like the iajc being executed is
pre-1.2.1 - what is the classpath you used in the ANT script to define the iajc
task? Was it pointing to an old install of AspectJ (<1.2.1) ?  The message
'Exception thrown from AspectJ 1.2' makes it sound like it was basic AspectJ
1.2.0 which did not understand this attribute.

Ironically this attribute has been added so that future weavers can know which
attributes will/won't exist in a class file and cope appropriately...

Comment 2 Marius Marin 2005-01-26 12:01:25 EST

That's correct! Thanks!

Now it is the same problem as in 1.2: if the original
jar (sources.jar) does not have any aspect, the jar
can be woven, but if it already has aspects, reweaving the jar
 fails.

It might be a problem with the Xreweavable option, as
the jars generated with or without this option are the
same size.

Comment 3 Andrew Clement 2005-01-26 12:12:14 EST

are you able to try building sources.jar from the command line suppling
-Xreweavable that way?  (I'm trying to ascertain if the problem is in the iajc
processing of that option or not). Reweavable versions of the classes should
definetly be larger.

Also, is it a problem if you need to build the initial sources.jar with javac &
jar - if there are no aspects in the input for sources.jar?

Comment 4 Marius Marin 2005-01-26 13:49:25 EST

It is the same problem from command line, too.

It works fine if sources.jar does not have any aspect. In this case (with no
aspect) the jar can be built with ajc and Xreweavable option (no need to use
javac + jar; "ajc -outjar" works) and supports (re)weaving (I can use it in
inpath). 
If the jar has aspects, apparently it cannot be re-woven (cannot be in inpath).

Comment 5 Wes Isberg 2005-01-26 21:30:10 EST

I've done minimal tests of reweaving an aspect and found no surprises, so we
might need to know more about your aspect to find out what the problem is.

For those writing test cases, here's how you'd specify it for the harness (after
updating):

<ajc-test dir="bugs/reweavable" pr="83717
    title="reweavable aspects">
    <compile 
      files="Reweavable.java" 
      options="-Xreweavable"
      outjar="rw.jar"/>
    <compile files="rw.jar"/>
    <run class="Reweavable"/>
</ajc-test>

I only tried a basic one, but the aspect does advise itself:

public class Reweavable {
    public static void main(String[] args) {
        System.out.println("in main");
    }
    static aspect A {
        public A() {}
        after() returning: execution(void A.foo()) {
            System.out.println("advising aspect method foo");
        }
        before() : execution(void main(String[])) {
            System.out.println("before main");
            foo();
        }
        void foo() {}
    }
}

Unless someone objects, I'll move this to the compiler component and reassign to
Andy.

Comment 6 Wes Isberg 2005-01-27 06:37:08 EST

reassigning as compiler/weaver issue...

Comment 7 Marius Marin 2005-01-27 08:23:19 EST

Here is the problem:

1. the code that works

package testreweave;

public interface InterfaceB {

    public void b();

}

//-----------

package testreweave;

public interface InterfaceA extends InterfaceB {
    
    public void a();
}

//-----------

package testreweave;

public class A implements InterfaceA {

    public void a() {
	System.out.println("A.a");
    }

    public void b() {
	System.out.println("introduced A.b");
    }
}

//-----------

package testreweave;

public privileged aspect IntroduceB {

//    declare parents: InterfaceA extends InterfaceB;

//    public void A.b() {
//	System.out.println("introduced A.b");
//    }

}

//-----------

With the sources above generate srcjar.jar:
>ajc -outjar srcjar.jar -argfile srclist1.lst -Xreweavable

//The aspect trying to reweave things
import testreweave.*;

public privileged aspect Reweave {
    
    public void InterfaceB.rewoven() {
        System.out.println("A.rewoven");
    }

   public void A.test() {
        A a = new A();
        a.rewoven();
   }
}

Compile: >ajc -d binsrc -argfile srclist2.lst -inpath srcjar.jar

and everything is fine.

******************

2. The code that doesn't work: uncomment the code in the aspect IntroduceB and 
comment out the corresponding code in the affected classes.

package testreweave;

public interface InterfaceB {

    public void b();

}

// -----------

package testreweave;

public interface InterfaceA /*extends InterfaceB*/ {
    
    public void a();
}

// -----------

package testreweave;

public privileged aspect IntroduceB {

    declare parents: InterfaceA extends InterfaceB;

    public void A.b() {
	System.out.println("introduced A.b");
    }

}

// -----------

package testreweave;

public class A implements InterfaceA {

    public void a() {
	System.out.println("A.a");
    }

    //    public void b() {
    //	System.out.println("introduced A.b");
    //    }


}

With the sources above generate srcjar.jar:
ajc -outjar srcjar.jar -argfile srclist1.lst -Xreweavable

//The aspect trying to reweave things
import testreweave.*;

public privileged aspect Reweave {
    
    public void InterfaceB.rewoven() {
        System.out.println("A.rewoven");
    }

   public void A.test() {
        A a = new A();
        a.rewoven();
   }
}

> ajc -d binsrc -argfile srclist2.lst -inpath srcjar.jar

..\TestReweave\src\Reweave.aj:11 error The method rewoven() is
 undefined for the type A
a.rewoven();


1 error, 1 warning

Hope I haven't missed anything and you can reproduce the error. I used 
aspectj1.2 for this example, but I think it's the same problem with 1.2.1

Comment 8 Adrian Colyer 2005-03-23 09:22:53 EST

for investigation in aj5m3

Comment 9 Andrew Clement 2005-06-22 03:34:41 EDT

not generics, postponing until after M3

Comment 10 Andrew Clement 2005-10-03 06:02:21 EDT

This is exactly the same problem as discussed in bug 108099.  When re-processing
a reweavable type that was targetted by ITDs we fail to take into account any
new ITDs and just apply the ones applied previously.  In this case the rewoven
method is never added to A because A was targetted by an ITD in a previous
compilation.

Comment 11 Andrew Clement 2005-10-03 07:52:33 EDT

Whilst looking at this bug, I found a problem when some systems containing ITDs
has been compiled with 1.2.1 and is to be processed with 1.5.  between 1.2.1 and
1.5.0 we have added the ability for type mungers (representing ITDs) to remember
their source location when they are serialized which enables us to do a better
job creating relationships in the structure model and reporting weaving info. 
We (I) didn't guard the loading of the source location based on whether an input
.class file was marked as being built with AspectJ5.  So we attempted to load
source locations for type mungers when the input code was built by 1.2 or 1.2.1
- this causes the classic EOFExceptions when processing attributes.

I've fixed it now ;)

Comment 12 Andrew Clement 2005-10-03 10:12:45 EDT

NPE fix and reweavable ITD fix checked in.  Effectively changed the code that
processes existing weaverstateinfo objects (which occur in reweavable types) -
original processing didn't allow for these types to be rewoven, but now it does.

I have *NOT* put this fix back into AspectJ1.2.1, it is only in AspectJ5 - it
could be backported if you desperately need it????

Comment 13 Andrew Clement 2005-10-04 03:41:13 EDT

Fix in 1.5.0 is available now - raised 111413 to cover a possible backport.