Community
Participate
Working Groups
When using AspectJ to weave already Java 7 built class files, the following exception appears: [java] Caused by: java.lang.VerifyError: Expecting a stackmap frame at branch target 15 in method TestBean.myMethod(Ljava/lang/Object;)V at offset 4 [java] at java.lang.Class.forName0(Native Method) [java] at java.lang.Class.forName(Class.java:264) Steps to reproduce: * Download the attached zip file * ensure JAVA_HOME is set to your Java 7 JDK * please update the jdk.home path in reproduce.properties also * ant -f reproduce.xml run This compiles the files using javac and weaves the class files. I stripped out all the code not necessary, so, the compiled result will not do what their class names suggest ;-) As a workaround one can use -XX:-UseSplitVerifier to activate the old verifier.
Created attachment 200632 [details] Project to reproduce the problem
I hope you manage to find the problem. Thanks for your help in advance! Mario
believed fixed. AspectJ now auto activates the previously optional setting to create stackmaps if the classes are Java7. Please reopen if still an issue.
Is this fix included in AJDT milestone released on 10/04? http://download.eclipse.org/tools/ajdt/37/milestone/ After updating to that milestone I'm still seeing this error.
Hi Mike - I would have thought it was but I'm not 100% sure I tried the changes out under AJDT, my testcases will have only tried it on the command line. Are you able to try out a dev build? If it still isn't working there we should reopen this.
I updated to latest dev build here: http://download.eclipse.org/tools/ajdt/37/dev/update/ I am getting the same error. Perhaps I just have an odd corner case in my code? If you cannot duplicate the issue with AJDT using your test case I'll see if I can create a test case. Here is an example trace when Spring IDE attempts to load the class: !MESSAGE Internal Error !STACK 0 java.lang.VerifyError: Expecting a stackmap frame at branch target 151 in method org.lds.keystone.view.ProjectController.getLinks(Ljavax/servlet/http/HttpServletRequest;)Ljava/util/List; at offset 43 at java.lang.Class.getDeclaredMethods0(Native Method) at java.lang.Class.privateGetDeclaredMethods(Class.java:2442) at java.lang.Class.getDeclaredMethods(Class.java:1808) at org.springframework.util.ReflectionUtils.doWithMethods(ReflectionUtils.java:467) at org.springframework.util.ReflectionUtils.doWithMethods(ReflectionUtils.java:451) at org.springframework.ide.eclipse.aop.core.internal.model.builder.AspectDefinitionMatcher.internalMatches(AspectDefinitionMatcher.java:272) at org.springframework.ide.eclipse.aop.core.internal.model.builder.AspectDefinitionMatcher.matches(AspectDefinitionMatcher.java:92) at org.springframework.ide.eclipse.aop.core.internal.model.builder.AopReferenceModelBuilderJob$1.doWithActiveProjectClassLoader(AopReferenceModelBuilderJob.java:251) at org.springframework.ide.eclipse.core.java.JdtUtils$DefaultProjectClassLoaderSupport.executeCallback(JdtUtils.java:889) at org.springframework.ide.eclipse.aop.core.internal.model.builder.AopReferenceModelBuilderJob.buildAopReferencesForBean(AopReferenceModelBuilderJob.java:207) at org.springframework.ide.eclipse.aop.core.internal.model.builder.AopReferenceModelBuilderJob.buildAopReferencesForBeans(AopReferenceModelBuilderJob.java:279) at org.springframework.ide.eclipse.aop.core.internal.model.builder.AopReferenceModelBuilderJob.buildAopReferencesForBeansConfig(AopReferenceModelBuilderJob.java:302) at org.springframework.ide.eclipse.aop.core.internal.model.builder.AopReferenceModelBuilderJob.buildAopReferencesFromBeansConfigSets(AopReferenceModelBuilderJob.java:401) at org.springframework.ide.eclipse.aop.core.internal.model.builder.AopReferenceModelBuilderJob.buildAopReferencesForFile(AopReferenceModelBuilderJob.java:359) at org.springframework.ide.eclipse.aop.core.internal.model.builder.AopReferenceModelBuilderJob.buildAopModel(AopReferenceModelBuilderJob.java:453) at org.springframework.ide.eclipse.aop.core.internal.model.builder.AopReferenceModelBuilderJob.run(AopReferenceModelBuilderJob.java:159) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
I am doing a Project->Clean so I don't believe it is trying to load some version of the class compiled with the old aspectj.
You could manually check the class to determine if it had the stackmap frame in: javap -private -verbose org.lds.keystone.view.ProjectController and check if the method shows a StackMap on it (and that the version number of the class file, up near the top, is 51). or - you could email me the class and I'll take a look. This would enable us to determine if it had a bad stackmap (missing a frame) or no stackmap at all.
Created attachment 207633 [details] Class file failing to be loaded Here is the class file that is failing to be loaded.
Created attachment 207634 [details] javap of ProjectController The class file version is 51. The org.aspectj.weaver.WeaverVersion is: 00 07 00 00 00 00 01 32 CC 21 E9 18 Is that correct? I don't see any StackMap information in the file.
let's reopen and I'll look at this when I get a sec
Ok, I have gotten to the bottom of this. It was due to the packaging process that puts AspectJ into AJDT. Another condition of building the stackmaps for Java7 verification is that the Asm classes are around to do so - if they aren't around the step is just skipped rather than throwing an error (this is a hangover from when during the stackmap gen was entirely optional). By Asm classes I mean the jarjar'd variant AspectJ uses (prefix is 'aj.'). The current packaging process wasn't including these in AJDT. When I adjust the packaging step to ensure these are included in the weaver jar for AJDT, it all works. Should be in an AJDT dev build later today (eclipse 3.7).
