Community
Participate
Working Groups
Build Identifier: During compilation of our project, we get a '(BCException) Bad type signature: ;'. The ajcore dump is attached to this bug. Unfortunately, I cannot share the project itself. Reproducible: Always
Created attachment 174714 [details] Core dump
From the exception in the dump: org.aspectj.weaver.BCException: Bad type signature: ; when weaving type nl.topicus.eduarte.web.pages.shared.RapportageConfiguratiePage$1$1 when weaving classes when weaving when batch building BuildConfig[null] #Files=2411 AopXmls=#0 at org.aspectj.weaver.UnresolvedType.signatureToName(UnresolvedType.java:738) at org.aspectj.weaver.UnresolvedType.signatureToName(UnresolvedType.java:704) looks like that type RapportageConfiguratiePage$1$1 (first anonymous inner of the first anonymous inner of RapportageConfiguratiePage) is referring to a parameterized type and the signature being dealt with is 'unusual' (and not handled properly). Is that type doing anything unusual with parameterized types?
There is some generics going on there, but nothing unusual. This is the constructor call of that inner type: new MultiEntityRapportageGenereerLink<R, S, ZF> With: public class MultiEntityRapportageGenereerLink <R extends IdObject, S extends IdObject, ZF extends DetachableZoekFilter<S>> extends AbstractRapportageGenereerLink public interface DetachableZoekFilter<T> extends ZoekFilter<T>, IDetachable public interface ZoekFilter<T> The main class is declared as: public class RapportageConfiguratiePage <R extends IBijlageKoppelEntiteit< ? extends BijlageEntiteit>, S extends IdObject, ZF extends DetachableZoekFilter<S>> extends AbstractDynamicContextPage<Void> implements IEditPage With: public interface IBijlageKoppelEntiteit<T extends BijlageEntiteit> extends IdObject I tried to create a minimal testcase, but cutting down the code seems to fix the problem. I also noticed that continuing the compilation seems to go fine, as if classes are compiled in the wrong order. The dump also seems to indicate this, as the class you mentioned, seems to be compiled before its superclass.
I'm still unable to create a minimal testcase, but I did find some strange behaviour: the bug is only triggered with certain file names. Renaming a class fixes the problem, which is quite strange, because that does not change the structure of the code in any way.
renaming a type can adjust the ordering in which files are compiled, and that can trigger issues as at different stages of compilation the files are represented by different data structures.
Created attachment 175041 [details] Minimal showcase I've finally managed to create a minimal case that still has the bug. It's a small maven project with 2 modules, commons and core. Commons is an aspect library dep of core (which is required to trigger the bug). Commons also contains 1 very simple aspect with a single 'declare error'. Most files in the tarball are empty, but still required to trigger the bug. I hope this helps.
Some more testing revealed that the name of the directory the tarball is extract to matters. On windows, you should extract the tarball to c:\eduarte (so the root pom.xml should be c:\eduarte\pom.xml), on Linux you should extract the tarball to /mnt/sda6/test/eduarte (with the pom.xml /mnt/sda6/test/eduarte/pom.xml). Some other directory names might also trigger the bug, but these are verified on several systems.
thanks for coming up with the testcase! The signature that the weaver is choking on is due to the declaration: Class< ? extends ZoekFilterDataAccessHelperCopy<S, ZoekFilterCopy<S>>>
Great to hear that the time I spent to create the testcase is not wasted and thanks for indicating the location in our code. It was quite to difficult to find the right set of files. It seems like the bug is triggered by a certain ordering of filenames in a hash. Do you have any idea if this can be fixed any time soon? For now, I've removed that method (it wasn't even used), which seems to help, but I'm afraid of hitting this bug in other places of the application. Signatures like that are not unusual in our application.
yes, things like this can behave differently depending on compile order (there are other routes to coming up with a signature). I have the fix working for me (it is easy once I could see the failing signature), but I'm looking at making a few tests whilst I'm in that area of the code as the coverage is a bit lacking.
fix likely to be out this week. My latest changes are triggering some test failures, but I suspect that means the tests need updating to the new (more correct) behaviour.
signature changes I want to make for now are in AspectJ (and should address this issue), when the build succeeds I'll try it out in AJDT and if that works, release a new AJDT.
That's good to hear. Is there any way we can use this build from Maven? I couldn't find a snapshot repository for the AspectJ compiler.
Per the AspectJ 1.6.9 readme: http://www.eclipse.org/aspectj/doc/released/README-169.html The snapshot repo is here: <repository> <id>maven.springframework.org</id> <name>SpringSource snapshots</name> <url>http://maven.springframework.org/snapshot</url> </repository> And the build tag is 1.6.10.BUILD-SNAPSHOT I just published a build there today, if you can confirm whether it fixes your situation that would be great. It does include some radical changes besides the fix but I wanted to start sorting out the signature handling properly rather than continuing to patch it up.
I've reverted the method to its old signature and checked with 1.6.9 (still fails) and 1.6.10-SNAPSHOT (compiles fine). It seems the bug is fixed and the compiler did not choke on any other method signatures in our project. Thanks for your very quick fix! We recently triggered a NPE in the Sun Java compiler, which was reported by someone else 1 year ago and still not fixed. We switched to the AspectJ compiler for that project, because it can compile the project.
Is the new AJDT available already? I don't see any updates in eclipse yet, and compilation is failing again due to the reverted signature.
there are some issues with the AJDT build process, the next build that actually succeeds will contain the changes
Fixed
