Summary: | AspectJ 1.6.9 break integration with cobertura | ||||||
---|---|---|---|---|---|---|---|
Product: | [Tools] AspectJ | Reporter: | Julien HENRY <julien.henry> | ||||
Component: | Compiler | Assignee: | aspectj inbox <aspectj-inbox> | ||||
Status: | NEW --- | QA Contact: | |||||
Severity: | major | ||||||
Priority: | P2 | CC: | aclement, wwong | ||||
Version: | 1.6.9 | ||||||
Target Milestone: | --- | ||||||
Hardware: | PC | ||||||
OS: | Windows Vista | ||||||
Whiteboard: | |||||||
Attachments: |
|
Description
Julien HENRY
2010-09-15 11:04:20 EDT
Created attachment 178944 [details]
Maven integration test
I hit similar issue on AspjectJ 1.6.12 for my codes =========================================================== ---- Compiler Messages --- info directory classpath entry does not exist: /opt/jdk1.6.0_30/jre/lib/sunrsasign.jar info directory classpath entry does not exist: /opt/jdk1.6.0_30/jre/lib/modules/jdk.boot.jar info zipfile classpath entry does not exist: /opt/jdk1.6.0_30/jre/classes abort ABORT -- (BCException) malformed org.aspectj.weaver.EffectiveSignature attribute (length:27)org.aspectj.weaver.BCException: Bad type signature touch when batch building BuildConfig[null] #Files=5 AopXmls=#0 --------------------------------------------------------------- After I switch to AspectJ 1.7.0.RC1, I don't see this issue but another issue appears: =========================================================== ---- AspectJ Properties --- AspectJ Compiler 1.7.0.RC1 built on Friday May 25, 2012 at 23:23:14 GMT ---- Dump Properties --- Dump file: ajcore.20120615.160521.469.txt Dump reason: java.lang.ClassCastException Dump on exception: true Dump at exit condition: abort ---- Exception Information --- java.lang.ClassCastException: org.aspectj.apache.bcel.classfile.ConstantMethodref cannot be cast to org.aspectj.apache.bcel.classfile.ConstantUtf8 at org.aspectj.apache.bcel.classfile.ConstantPool.getConstantUtf8(ConstantPool.java:223) at org.aspectj.weaver.bcel.BcelConstantPoolReader.readUtf8(BcelConstantPoolReader.java:31) at org.aspectj.weaver.VersionedDataInputStream.readUtf8(VersionedDataInputStream.java:61) at org.aspectj.weaver.ResolvedMemberImpl.readResolvedMember(ResolvedMemberImpl.java:500) at org.aspectj.weaver.AjAttribute$EffectiveSignatureAttribute.read(AjAttribute.java:734) Per the first comment, I downloaded the attached project and ran 'mvn clean compile', it worked OK. It appeared to be using 1.6.9, I tried it with 1.6.8 and same result. The problem with 'Bad type signature' and 'org.aspectj.apache.bcel.classfile.ConstantMethodref cannot be cast to org.aspectj.apache.bcel.classfile.ConstantUtf8' both suggest that something has modified the class file and not preserved the constant pool contents/ordering. Some ways of using the Asm bytecode toolkit don't preserve the pool, attempting to optimize it and not recognizing other class file attributes may point into it (not annotations). Wai-Tak, are you using cobertura? Do you know at what point cobertura runs, is it instrumenting source code or bytecode when you run it? Are you loadtime weaving as well or just doing a regular compile? These orderings of operations should be fine: aspectJ compile source > cobertura instruments binaries > code runs ok Java compiles > Cobertura instruments binaries > aspectj binary weave > code runs ok Cobertura instruments sources > AspectJ Compiles > code runs ok Cobertura instruments sources > Java Compiles > AspectJ binary weave > code runs ok This type of ordering won't run, if cobertura affects the contents/ordering of the class constant pool: aspectj compile source > cobertura instruments binaries > second aspectj binary weave (BANG) aspectj compile source > cobertura instruments binaries > loadtime weaving runs (BANG) java compiles > aspectj weave > cobertura instruments binaries > loadtime weave (BANG) It is possible that on a non-clean incremental compile that AspectJ is seeing some files that have been through the cobertura weave step, and is attempting to understand them. With the modified constant pools it cannot understand them and fails. Or if there are multiple compile steps and any one of those steps sees code that originally went through aspectj followed by cobertura - it will fail like this. unsetting the target field which is currently set for something already released |