Community
Participate
Working Groups
I've been having this issue in many projects using 1.7.3 and Java 1.6. I'm not entirely sure that this happens with the AJC standalone or only inside Eclipse Kepler. I don't recall having such issues with previous versions of Eclipse. First of all it only happens when using JaCoCo for code coverage. JaCoCo folks say AspectJ is to blame since it is not producing valid classes: "in any case JaCoCo requires valid classfiles as input. This implies that class files from version 1.6 on need to contain valid stackmap frames. If this is not the case JaCoCo will fail with exactly this message." I then end up getting no coverage information on many classes that use aspects. The workaround some people used is to upgrade to Java 1.7 and changes AspectJ conf for complianceLevel, target and source to 1.7. Unfortunately that is not an option for me.
On the front end AspectJ relies on JDT core for creating the stack maps but on the backend AspectJ uses asm to compute the stack map frames. I presume this is a message you can't turn off with -XX:-UseSplitVerifier? It would depend on whether it is the JVM policing it or the JaCoCo framework itself. Have you tried AspectJ 1.8.0.M1 - I'd be interested in whether that makes any difference because it uses a different version of asm (you don't need to upgrade to 1.8, you can continue using 1.6) If you could share a problematic class with me, that would be useful.
Andrew, the validation is performed by JaCoCo itself, using -XX:-UseSplitVerifier doesn't make any difference in this case. Since I'm running from inside Eclipse Kepler, I believe I'm stuck with 1.7.3 that comes bundled with it. Do you know a way to replace that with 1.8.0.M1? I'll see if I can anonymize a project to provide you a problematic class file. To be honest I didn't understand your statement about frontend and backend. Something that I also find rather strange is the option to switch on and off the weaving service in Eclipse. With weaving service off I still get aspects on my classes, but the resulting classes are very, very different than when it is on. The classes generated with the Maven build are similar if not equal to the ones with weaving service on. But that is something else, not related to this problem.
> Since I'm running from inside Eclipse Kepler, I believe I'm stuck with 1.7.3 > that comes bundled with it. Do you know a way to replace that with 1.8.0.M1? The latest AJDT builds for Kepler include 1.8.0 builds so should give you a 1.8.0 weaver. But anyway, on thinking about it a little more I wonder if the route you are taking with the weaving is influencing things: > Something that I also find rather strange is the option to switch on > and off the weaving service in Eclipse. I didn't realise this involved the weaving service. I wonder if that route to the weaver is not setting the flags appropriately to ensure stack maps are being added. (I notice you mentioning Java 1.6 where stack maps are *actually* optional, so JaCoCo strictly requiring them is a little overzealous). If you are on 1.6 you can force them by setting this property: -Xset:generateStackMaps=true But I don't know if you have a way to set those settings with the weaving service (typically that would go in an aop.xml in the weaver options section). Another option would be use Java 1.7 which will auto trigger AspectJ to include the stackmap frames because they are required at that Java level.
I didn't upgrade to the latest Kepler (2.0.1.20130919-0803) due to an issue that I cannot live with (417458). So on Eclipse I'm stuck with 1.7.3 for a while. Though, thanks to your comments, I was able to solve half of my problems :)) Added this: <Xset> <generateStackMaps>true</generateStackMaps> </Xset> to my Maven configuration and it worked! My Maven/Sonar build is ok now, just Eclipse remains with the problem.
Glad that has gotten you part of the way. I believe aop.xml is supported for in eclipse weaving, you just need to put the aop.xml file in the right place. Do you have a META-INF/aop.xml in the bundles defining the aspects? I think that is where it will be looking for the configuration. I also saw a MANIFEST.MF config option: Eclipse-AspectContext: META-INF/aspects/aop.xml for specifying if you have put it somewhere else. Within that file you'd need: <aspectj> <weaver options="-Xset:generateStackMaps=true"/> </aspectj>
I was finally able to make it work inside Eclipse! Using a custom aop.xml with <weaver options="-Xset:generateStackMaps=true"/> does *not* work. Instead of that, what worked was to go to Preferences -> AspectJ Compiler and add "-Xset:generateStackMaps=true", without quotes, to the Non-standard compiler options. Thanks for Andrew for the pointers!
Hi, Does this option (-Xset:generateStackMaps=true) work with the iajc Ant task? I have this same issue and we're stuck on Java 1.6. We're using Jacoco via SonarQube and getting these same errors. The project is old and uses Ant to build. Thanks (In reply to Andrew Clement from comment #5) > Glad that has gotten you part of the way. I believe aop.xml is supported for > in eclipse weaving, you just need to put the aop.xml file in the right place. > > Do you have a META-INF/aop.xml in the bundles defining the aspects? I think > that is where it will be looking for the configuration. I also saw a > MANIFEST.MF config option: > > Eclipse-AspectContext: META-INF/aspects/aop.xml > > for specifying if you have put it somewhere else. Within that file you'd > need: > > <aspectj> > <weaver options="-Xset:generateStackMaps=true"/> > </aspectj>
