Open GoogleCodeExporter opened 9 years ago
Confirmed - VerifyErrors vanished from my setup.
btw: one test fails when building javassist trunk (called "150b" or so)...
Original comment by moldowan.android@googlemail.com
on 25 Sep 2012 at 9:17
[deleted comment]
Great news! Thanks everyone for helping out.
Original comment by johan.ha...@gmail.com
on 26 Sep 2012 at 6:11
Yes javassist-3.17.0-GA.jar now works for my PowerMock tests also.
Original comment by desmond.kirrane
on 26 Sep 2012 at 11:23
Warning -- -XX:-UseSplitVerifier is dangerous and led to spooky errors when
combined with PowerMock and Java 7.
'-XX:-UseSplitVerifier' fixed the verification errors, but led to other problems. JUnit tests that were not using PowerMock were failing badly -- static references were seemingly substituted and replaced (e.g. a singleton changed from the POV of a non-Powermock test).
Building the trunk javassist (javassist-3.17.0-GA.jar) and using that with the
default Java 7 verifier worked fine.
javassist needs a new release with this change badly.
Original comment by scott.ca...@gmail.com
on 29 Sep 2012 at 12:36
I'm more or less ready to release a new version of PowerMock but do you think I
should wait until the next Javassist release before I do so?
Original comment by johan.ha...@gmail.com
on 29 Sep 2012 at 10:18
I think you should wait as this seems to be a top issue for many powermock
users.
Original comment by moldowan.android@googlemail.com
on 29 Sep 2012 at 10:32
If you don't plan to release some new killer features or major bug fixes, you
should wait for the next Javassist release. Just my 2 cents.
Original comment by i...@kjeld.de
on 29 Sep 2012 at 10:55
The main new features are probably support for Mockito 1.9-rc1 and that JUnit
rules finally works for JUnit 4.9+. But maybe it's better to wait just as you
say.
Original comment by johan.ha...@gmail.com
on 29 Sep 2012 at 12:02
Hi,
I confirm the bugfix for the testsample of comment 42. But we still get the
VerifyError, when we test a class extending the SwingWorker-class. The error
occurs by initializing the inner class of the SwingWorker. I have attached the
modified example using a swingworker like in our own application.
Original comment by thomas.h...@googlemail.com
on 2 Oct 2012 at 9:08
Attachments:
Here is the stacktrace:
java.lang.VerifyError: Inconsistent stackmap frames at branch target 53 in
method
javax.swing.SwingWorker$SwingWorkerPropertyChangeSupport.<init>(Ljavax/swing/Swi
ngWorker;Ljava/lang/Object;)V at offset 39
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:186)
at javassist.runtime.Desc.getClassObject(Desc.java:43)
at javassist.runtime.Desc.getClassType(Desc.java:152)
at javassist.runtime.Desc.getType(Desc.java:122)
at javassist.runtime.Desc.getType(Desc.java:78)
at javax.swing.SwingWorker.<init>(SwingWorker.java:309)
at powermocktest.SuperClass.<init>(SuperClass.java:5)
at powermocktest.ClassUnderTest.<init>(ClassUnderTest.java:8)
at powermocktest.PowerMockTest.test(PowerMockTest.java:18)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.junit.internal.runners.TestMethod.invoke(TestMethod.java:66)
at org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl$PowerMockJUnit44MethodRunner.runTestMethod(PowerMockJUnit44RunnerDelegateImpl.java:312)
at org.junit.internal.runners.MethodRoadie$2.run(MethodRoadie.java:86)
at org.junit.internal.runners.MethodRoadie.runBeforesThenTestThenAfters(MethodRoadie.java:94)
at org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl$PowerMockJUnit44MethodRunner.executeTest(PowerMockJUnit44RunnerDelegateImpl.java:296)
at org.powermock.modules.junit4.internal.impl.PowerMockJUnit47RunnerDelegateImpl$PowerMockJUnit47MethodRunner.executeTestInSuper(PowerMockJUnit47RunnerDelegateImpl.java:112)
at org.powermock.modules.junit4.internal.impl.PowerMockJUnit47RunnerDelegateImpl$PowerMockJUnit47MethodRunner.executeTest(PowerMockJUnit47RunnerDelegateImpl.java:73)
at org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl$PowerMockJUnit44MethodRunner.runBeforesThenTestThenAfters(PowerMockJUnit44RunnerDelegateImpl.java:284)
at org.junit.internal.runners.MethodRoadie.runTest(MethodRoadie.java:84)
at org.junit.internal.runners.MethodRoadie.run(MethodRoadie.java:49)
at org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl.invokeTestMethod(PowerMockJUnit44RunnerDelegateImpl.java:209)
at org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl.runMethods(PowerMockJUnit44RunnerDelegateImpl.java:148)
at org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl$1.run(PowerMockJUnit44RunnerDelegateImpl.java:122)
at org.junit.internal.runners.ClassRoadie.runUnprotected(ClassRoadie.java:34)
at org.junit.internal.runners.ClassRoadie.runProtected(ClassRoadie.java:44)
at org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl.run(PowerMockJUnit44RunnerDelegateImpl.java:120)
at org.powermock.modules.junit4.common.internal.impl.JUnit4TestSuiteChunkerImpl.run(JUnit4TestSuiteChunkerImpl.java:102)
at org.powermock.modules.junit4.common.internal.impl.AbstractCommonPowerMockRunner.run(AbstractCommonPowerMockRunner.java:53)
at org.powermock.modules.junit4.PowerMockRunner.run(PowerMockRunner.java:42)
at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50)
at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
Original comment by thomas.h...@googlemail.com
on 2 Oct 2012 at 9:09
Thomas, you should report that here as well:
https://issues.jboss.org/browse/JASSIST-160
Original comment by moldowan.android@googlemail.com
on 4 Oct 2012 at 2:45
I saw that. I will check the new test. Hope will be fixed before the release.
Original comment by shigeru....@gmail.com
on 5 Oct 2012 at 3:57
I have fixed this problem. Can anyone confirm this? Thanks!
Original comment by shigeru....@gmail.com
on 6 Oct 2012 at 2:49
Yes, I can confirm the bugfix. Now the sample projects works fine as well as
the tests in our own project. Now the only step to do is release the javassist
and modify the maven dependency for powermock to the new version. Than
everything is fine :). Thanks. Great work.
Original comment by thomas.h...@googlemail.com
on 8 Oct 2012 at 12:26
Nice, great job! Can't wait for the upcoming javassist release. :)
Original comment by i...@kjeld.de
on 8 Oct 2012 at 12:29
I've said this numerous times before but thanks a lot everyone for helping out.
My plan is to release PowerMock as soon as the next version of Javassist is
released.
Original comment by johan.ha...@gmail.com
on 8 Oct 2012 at 12:54
[deleted comment]
I'd like to add another error message that seems to be the result of this same
bug:
java.lang.VerifyError: Bad type on operand stack in aaload in method
org.foo.bar.FooBar.<init>()V at offset 101
My test involves mocking construction of a new object using
PowerMockito.whenNew(). Researching this problem led me here, and applying the
latest javassist-3.17.0-GA.jar resolved this error in my test.
Original comment by oliverhe...@gmail.com
on 12 Oct 2012 at 5:37
Thank you for the great work on fixing this issue. I would also like to confirm
that version 3.17.0-GA fixed all "inconsistent stackmap" issues I had on my
project with Java 1.7 and Powermock.
Any update on the release date for 3.17.0-GA?
Original comment by ja...@midtgaard-olesen.dk
on 15 Oct 2012 at 8:17
The trunk of javassit fixed most of our promblems however we are still getting
some issues. Any ideas?
Exception in thread "main" java.lang.IllegalStateException: Failed to transform
class with name xxx.xxxxx.xxxxx.xxxxxx. Reason: null
at org.powermock.core.classloader.MockClassLoader.loadMockClass(MockClassLoader.java:207)
at org.powermock.core.classloader.MockClassLoader.loadModifiedClass(MockClassLoader.java:145)
at org.powermock.core.classloader.DeferSupportingClassLoader.loadClass(DeferSupportingClassLoader.java:67)
at java.lang.ClassLoader.loadClass(ClassLoader.java:356)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:264)
at sun.reflect.generics.factory.CoreReflectionFactory.makeNamedType(CoreReflectionFactory.java:114)
at sun.reflect.generics.visitor.Reifier.visitClassTypeSignature(Reifier.java:125)
at sun.reflect.generics.tree.ClassTypeSignature.accept(ClassTypeSignature.java:49)
at sun.reflect.annotation.AnnotationParser.parseSig(AnnotationParser.java:390)
at sun.reflect.annotation.AnnotationParser.parseClassValue(AnnotationParser.java:371)
at sun.reflect.annotation.AnnotationParser.parseClassArray(AnnotationParser.java:673)
at sun.reflect.annotation.AnnotationParser.parseArray(AnnotationParser.java:480)
at sun.reflect.annotation.AnnotationParser.parseMemberValue(AnnotationParser.java:306)
at sun.reflect.annotation.AnnotationParser.parseAnnotation(AnnotationParser.java:241)
at sun.reflect.annotation.AnnotationParser.parseAnnotations2(AnnotationParser.java:88)
at sun.reflect.annotation.AnnotationParser.parseAnnotations(AnnotationParser.java:70)
at java.lang.Class.initAnnotationsIfNecessary(Class.java:3089)
at java.lang.Class.getAnnotations(Class.java:3069)
at org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl.classAnnotations(PowerMockJUnit44RunnerDelegateImpl.java:165)
at org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl.getDescription(PowerMockJUnit44RunnerDelegateImpl.java:157)
at org.powermock.modules.junit4.common.internal.impl.JUnit4TestSuiteChunkerImpl.getDescription(JUnit4TestSuiteChunkerImpl.java:172)
at org.powermock.modules.junit4.common.internal.impl.AbstractCommonPowerMockRunner.getDescription(AbstractCommonPowerMockRunner.java:47)
at org.powermock.modules.junit4.PowerMockRunner.run(PowerMockRunner.java:40)
at junit.framework.JUnit4TestAdapter.run(JUnit4TestAdapter.java:39)
at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:520)
at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:1060)
at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:884)
Caused by: java.lang.NullPointerException
at javassist.bytecode.stackmap.TypeData.commonSuperClassEx(TypeData.java:400)
at javassist.bytecode.stackmap.TypeData$TypeVar.fixTypes2(TypeData.java:342)
at javassist.bytecode.stackmap.TypeData$TypeVar.fixTypes(TypeData.java:325)
at javassist.bytecode.stackmap.TypeData$TypeVar.dfs(TypeData.java:270)
at javassist.bytecode.stackmap.MapMaker.fixTypes(MapMaker.java:287)
at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:140)
at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:99)
at javassist.bytecode.MethodInfo.rebuildStackMap(MethodInfo.java:423)
at javassist.bytecode.MethodInfo.rebuildStackMapIf6(MethodInfo.java:405)
at javassist.expr.ExprEditor.doit(ExprEditor.java:113)
at javassist.CtClassType.instrument(CtClassType.java:1398)
at org.powermock.core.transformers.impl.MainMockTransformer.transform(MainMockTransformer.java:75)
at org.powermock.core.classloader.MockClassLoader.loadMockClass(MockClassLoader.java:203)
... 27 more
and :
java.lang.VerifyError: Stack map does not match the one at exception handler
2290 in method xxx.xxxxx.xxx.xxxxxxx.xxxxxxxx()Ljava/lang/String; at offset 686
at java.lang.Class.getDeclaredMethods0(Native Method)
at java.lang.Class.privateGetDeclaredMethods(Class.java:2442)
at java.lang.Class.getMethod0(Class.java:2685)
at java.lang.Class.getMethod(Class.java:1620)
at org.easymock.internal.ObjectMethodsFilter.<init>(ObjectMethodsFilter.java:55)
at org.easymock.internal.MocksControl.createMock(MocksControl.java:59)
at org.powermock.api.easymock.PowerMock.doCreateMock(PowerMock.java:2212)
at org.powermock.api.easymock.PowerMock.doMock(PowerMock.java:2163)
at org.powermock.api.easymock.PowerMock.createMock(PowerMock.java:89)
at xxx.xxxx.xxx.xxxx.xxxxxxxxxxxxxxTest.testxxxxxxxxxx(xxxxxxxxxxxxxxTest.java:93)
at org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl$PowerMockJUnit44MethodRunner.runTestMethod(PowerMockJUnit44RunnerDelegateImpl.java:312)
at org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl$PowerMockJUnit44MethodRunner.executeTest(PowerMockJUnit44RunnerDelegateImpl.java:296)
at org.powermock.modules.junit4.internal.impl.PowerMockJUnit47RunnerDelegateImpl$PowerMockJUnit47MethodRunner.executeTestInSuper(PowerMockJUnit47RunnerDelegateImpl.java:112)
at org.powermock.modules.junit4.internal.impl.PowerMockJUnit47RunnerDelegateImpl$PowerMockJUnit47MethodRunner.executeTest(PowerMockJUnit47RunnerDelegateImpl.java:73)
at org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl$PowerMockJUnit44MethodRunner.runBeforesThenTestThenAfters(PowerMockJUnit44RunnerDelegateImpl.java:284)
at org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl.invokeTestMethod(PowerMockJUnit44RunnerDelegateImpl.java:209)
at org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl.runMethods(PowerMockJUnit44RunnerDelegateImpl.java:148)
at org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl$1.run(PowerMockJUnit44RunnerDelegateImpl.java:122)
at org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl.run(PowerMockJUnit44RunnerDelegateImpl.java:120)
at org.powermock.modules.junit4.common.internal.impl.JUnit4TestSuiteChunkerImpl.run(JUnit4TestSuiteChunkerImpl.java:102)
at org.powermock.modules.junit4.common.internal.impl.AbstractCommonPowerMockRunner.run(AbstractCommonPowerMockRunner.java:53)
at org.powermock.modules.junit4.PowerMockRunner.run(PowerMockRunner.java:42)
Original comment by jbainbr...@gmail.com
on 15 Oct 2012 at 3:08
I have publicly released Javassist 3.17.0-GA although the bug reported by
Comment 71 has not been tested.
To investigate this bug, I need the javap dump of the class file VerifyError is
reported on.
Original comment by shigeru....@gmail.com
on 9 Nov 2012 at 2:05
Stack map does not match the one at exception handler 2290 in method
xxx.xxxx.xxx.xxxx.xxxx()Ljava/lang/String; at offset 686
java.lang.VerifyError: Stack map does not match the one at exception handler
2290 in method com.xxx.xxx.xxxx.xxxxxx()Ljava/lang/String; at offset 686
at java.lang.Class.getDeclaredMethods0(Native Method)
at java.lang.Class.privateGetDeclaredMethods(Class.java:2442)
at java.lang.Class.getMethod0(Class.java:2685)
at java.lang.Class.getMethod(Class.java:1620)
at org.easymock.internal.ObjectMethodsFilter.<init>(ObjectMethodsFilter.java:55)
at org.easymock.internal.MocksControl.createMock(MocksControl.java:59)
at org.powermock.api.easymock.PowerMock.doCreateMock(PowerMock.java:2212)
at org.powermock.api.easymock.PowerMock.doMock(PowerMock.java:2163)
at org.powermock.api.easymock.PowerMock.createMock(PowerMock.java:89)
at com.xactnet.itr.reports.YearOverYearKeyCompositeITRReportTest.testGetInformationForCorda(YearOverYearKeyCompositeITRReportTest.java:93)
at org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl$PowerMockJUnit44MethodRunner.runTestMethod(PowerMockJUnit44RunnerDelegateImpl.java:312)
at org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl$PowerMockJUnit44MethodRunner.executeTest(PowerMockJUnit44RunnerDelegateImpl.java:296)
at org.powermock.modules.junit4.internal.impl.PowerMockJUnit47RunnerDelegateImpl$PowerMockJUnit47MethodRunner.executeTestInSuper(PowerMockJUnit47RunnerDelegateImpl.java:112)
at org.powermock.modules.junit4.internal.impl.PowerMockJUnit47RunnerDelegateImpl$PowerMockJUnit47MethodRunner.executeTest(PowerMockJUnit47RunnerDelegateImpl.java:73)
at org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl$PowerMockJUnit44MethodRunner.runBeforesThenTestThenAfters(PowerMockJUnit44RunnerDelegateImpl.java:284)
at org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl.invokeTestMethod(PowerMockJUnit44RunnerDelegateImpl.java:209)
at org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl.runMethods(PowerMockJUnit44RunnerDelegateImpl.java:148)
at org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl$1.run(PowerMockJUnit44RunnerDelegateImpl.java:122)
at org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl.run(PowerMockJUnit44RunnerDelegateImpl.java:120)
at org.powermock.modules.junit4.common.internal.impl.JUnit4TestSuiteChunkerImpl.run(JUnit4TestSuiteChunkerImpl.java:102)
at org.powermock.modules.junit4.common.internal.impl.AbstractCommonPowerMockRunner.run(AbstractCommonPowerMockRunner.java:53)
at org.powermock.modules.junit4.PowerMockRunner.run(PowerMockRunner.java:42)
Original comment by jbainbr...@gmail.com
on 9 Nov 2012 at 3:33
I'm missing the new Javassist release 3.17.0-GA in maven central. Who is
usually deploying the artifact?
I found a detailed HOWTO on how to publish it:
https://community.jboss.org/wiki/PublishingJavassistReleasesToSonatypePublicRepo
mavenCentral?_sscc=t
Original comment by i...@kjeld.de
on 9 Nov 2012 at 4:15
So it's released! That's great news. Please keep us posted when it pops up on
maven central and I'll release PowerMock unless something unexpected happens.
Original comment by johan.ha...@gmail.com
on 9 Nov 2012 at 4:30
3.17 is live on maven central now.
http://repo2.maven.org/maven2/org/javassist/javassist/3.17.0-GA/
Anxiously awaiting the next Powermock release!
Original comment by DanFabul...@gmail.com
on 14 Nov 2012 at 8:44
Cool! Thanks for notifying me. I'm at devoxx right now but hopefully I can find
some time to release during the weekend.
Original comment by johan.ha...@gmail.com
on 14 Nov 2012 at 1:07
Hmm I run into "javassist/CtClass.class(javassist:CtClass.class): major version
51 is newer than 50, the highest major version supported by this compiler" when
I try to build PowerMock with the 3.17 of Javassist in Java 6 and so Maven
won't build it. Any ideas?
Original comment by johan.ha...@gmail.com
on 14 Nov 2012 at 1:51
So it works when I switch to JDK 7. But what exactly does this mean? The goal
is that PowerMock should support Java 5.
Original comment by johan.ha...@gmail.com
on 14 Nov 2012 at 1:56
First of all, congratulations on a job well done regarding PowerMock! :)
Bare with me because what will follow is a lot of guesswork. Hope it will help
you a little bit even so! :)
'Major version 51 is newer than 50' only indicates that the class-file is
compiled with a Java 7-compiler. That's why it works in JDK7 and not 6.
If I'm guessing right then Javassist needs to publish other jars (using a
different compiler or specifying the java compatibility version with '-target').
Original comment by lars.pan...@gmail.com
on 14 Nov 2012 at 7:02
Actually, Javassist are already aware of the problem. See the link below.
https://issues.jboss.org/browse/JASSIST-163
Original comment by lars.pan...@gmail.com
on 14 Nov 2012 at 7:33
I've filed https://issues.jboss.org/browse/JASSIST-178 on the Java 7 bug,
linking back to the conversation in JASSIST-163 (JASSIST-163 is not relevant to
this powermock issue #355 or JASSIST-178, but JASSIST-178 was discussed in
comments on JASSIST-163.)
Original comment by dan.fabu...@redfin.com
on 14 Nov 2012 at 9:24
Guess we should wait until a new Javassist binary is relased to Maven central
then or what do you guys think?
Original comment by johan.ha...@gmail.com
on 15 Nov 2012 at 8:19
While we wait for the new binaries maybe we could compile the Javassist source
ourselves so we're not stuck? I mean, we don't know how long we'll have to wait
for the new binaries in Maven central.
Original comment by lars.pan...@gmail.com
on 15 Nov 2012 at 8:33
Self compiling is just a workaround. The publishing process of Javassist is
kind of lame. Takes several days after a new release to publish it in maven
central and is then "broken". :(
Original comment by i...@kjeld.de
on 15 Nov 2012 at 8:39
I will release 3.17.1 within a few days, which will be compiled by Java 6 and
fix another bug.
I agree that the release engineering of Javassist is a kind of lame. It's a
long lasting project (more than a decade!) and it is currently maintained
almost only by me (the project founder) and released through a guy at
Redhat/JBoss.
Original comment by shigeru....@gmail.com
on 19 Nov 2012 at 8:17
I think this is totally understandable. PowerMock has been around since 2007
and I'm more or less in the same situation that you are. It's not easy to get
everything right by yourself. I think Javassist is an awesome project and
without it PowerMock probably wouldn't exist.
Did you compile it against Java 6 in releases prior to 3.17? I'm wondering
since I would really like PowerMock to work for Java >= 5 and not run into the
'Major version 51 is newer than 50' problem again.
Original comment by johan.ha...@gmail.com
on 19 Nov 2012 at 10:30
Thanks for your understanding. When I started the project, I was young and had
lots of time for coding but nowadays I am getting to be a "the boss"-like
professor (I'm working for university) who is always busy with administration
and losing time for coding. :-(
Javassist can be compiled even by Java 4. So Java 5 is also fine. One concern
is that the binary compiled by Java 4 or 5 does not contain stack map tables,
which will cause a bit slowdown on the Java 6 or 7 VM.
Any inputs?
Original comment by shigeru....@gmail.com
on 19 Nov 2012 at 3:33
Shigeru, thank you for your hard work on finalising the Javassist
3.17GA-release! I've been eagerly following a few of the related
Javassist-issues. Keep up the good work! :)
I would suggest that you keep at least Java 5 compatibility so that most
Maven-users won't run into version incompatibility problems. But that also
depends on how severe the performance penalty is?
Original comment by lars.pan...@gmail.com
on 19 Nov 2012 at 7:37
3.17.1 is live on maven central now; it's now backwards compatible with Java
1.4. http://repo2.maven.org/maven2/org/javassist/javassist/3.17.1-GA/
Let's do this! :-)
Original comment by DanFabul...@gmail.com
on 3 Dec 2012 at 6:19
I've released a new version now, it should be available in Maven central soon.
BIG thanks to everyone for helping out.
Original comment by johan.ha...@gmail.com
on 4 Dec 2012 at 12:10
Hi, sorry for reviving this thread, but I seem to have gotten into a very
similar issue.
It only appears when running the full suite of JUnit tests, the individual
(failed) test runs fine.
I'm using PowerMock 1.5 (with easymock) on JDK 7 along with junit4 in Eclipse.
In the stacktrace below 'ServiceType' is actually an enum, it is not mocked
itself but there is 1 static mocked: java.sql.DriverManager (other mocked
objects are related interfaces like Connection and PreparedStatement)
Stacktrace:
Caused by: java.lang.VerifyError: Expecting a stackmap frame at branch target
10 in method
javax.xml.parsers.DocumentBuilderFactory.newInstance(Ljava/lang/String;Ljava/lan
g/ClassLoader;)Ljavax/xml/parsers/DocumentBuilderFactory; at offset 0
at org.apache.log4j.xml.DOMConfigurator.doConfigure(DOMConfigurator.java:854)
at org.apache.log4j.xml.DOMConfigurator.doConfigure(DOMConfigurator.java:778)
at org.apache.log4j.helpers.OptionConverter.selectAndConfigure(OptionConverter.java:526)
at org.apache.log4j.LogManager.<clinit>(LogManager.java:127)
at org.apache.log4j.Logger.getLogger(Logger.java:117)
at be.persgroep.akamai.services.ServiceType.<clinit>(ServiceType.java:84)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:186)
at javassist.runtime.Desc.getClassObject(Desc.java:43)
at javassist.runtime.Desc.getClazz(Desc.java:52)
at be.persgroep.akamai.test.ServiceTypeTest.getNonExistingIDInsertError(ServiceTypeTest.java:191)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.junit.internal.runners.TestMethod.invoke(TestMethod.java:66)
at org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl$PowerMockJUnit44MethodRunner.runTestMethod(PowerMockJUnit44RunnerDelegateImpl.java:312)
... 23 more
Original comment by redalert.commander@gmail.com
on 8 Jan 2013 at 1:03
Interestingly, this occurs when selecting run as - junit test from the context
menu of the source folder in eclipse. When running from the maven pom file all
tests are successful.
Original comment by redalert.commander@gmail.com
on 8 Jan 2013 at 1:09
These are the worst kind of errors and it's almost impossible to know what
could be the reason for it :( Have you explicitly tried to prepare the
DocumentBuilderFactory for test? Otherwise you can try to ignore everything in
the "javax.*" package (by using @PowerMockIgnore).
Original comment by johan.ha...@gmail.com
on 8 Jan 2013 at 1:37
The only log4j related actions on my behalf are a JVM paramter
(-Dlog4j.configuration=file) and the usual private static final Logger = ...
I just tried the @PowerMockIgnore annotation, but that seems to create other
problems.
first I ignored javax.*, which resulted in the same error but on the
DocumentBuilderFactoryImpl class from xerces in com.sun. Ignoring com.sun as
well results in a totally different error:
java.lang.LinkageError: loader constraint violation: when resolving method
"javax.xml.parsers.DocumentBuilder.setErrorHandler(Lorg/xml/sax/ErrorHandler;)V"
the class loader (instance of org/powermock/core/classloader/MockClassLoader)
of the current class, org/apache/log4j/xml/DOMConfigurator, and the class
loader (instance of <bootloader>) for resolved class,
javax/xml/parsers/DocumentBuilder, have different Class objects for the type
s.DocumentBuilder.setErrorHandler(Lorg/xml/sax/ErrorHandler;)V used in the
signature
After that one, another for org.w3c, now I finally got this:
@PowerMockIgnore({"javax.*", "com.sun*", "org.xml.*", "org.w3c.*" })
but it works.
Another test, that's not using PowerMock, still fails with this message:
java.lang.VerifyError: Expecting a stackmap frame at branch target 16 in method
com.example.xxxx.RealMain.realMain([Ljava/lang/String;Ljava/io/PrintStream;Ljava
/io/PrintStream;)V at offset 6
Original comment by redalert.commander@gmail.com
on 8 Jan 2013 at 3:10
Perhaps you could try the Java agent approach?
http://code.google.com/p/powermock/wiki/PowerMockAgent
Original comment by johan.ha...@gmail.com
on 8 Jan 2013 at 6:35
There is 1 test that fails as soon as I replace
'@RunWith(PowerMockRunner.class)' with
@Rule
public final PowerMockRule rule = new PowerMockRule();
(inside the class body)
java.lang.VerifyError: Expecting a stackmap frame at branch target 306 in
method
com.example.xxxxx.xxxxxx.ServiceType.getXxx(Ljava/lang/String;Ljava/lang/String;
)I at offset 7
Adding this class to @PrepareForTest reveals another, then another, etc. until
I reach the second one from the com.sun package, I can't add that one due to
visibility of the class (com.sun.crypto.provider.CipherCore).
I take it that this method of invoking PowerMock would actually work if I fix
my test, it is doing calls to a webservice which a test shouldn't do (haven't
mocked these yet).
Thanks for your help.
Original comment by redalert.commander@gmail.com
on 9 Jan 2013 at 9:30
Small addition to that last comment, the failing test doesn't actually use
PowerMock yet, it only fails because the classes are already loaded because of
previous tests.
It would run fine on its own.
Original comment by redalert.commander@gmail.com
on 9 Jan 2013 at 9:32
I'm also getting similar error:
java.lang.VerifyError: Expecting a stackmap frame at branch target 90
Exception Details:
Location:
com/example/Util.<clinit>()V @32: if_acmpeq
Reason:
Expected stackmap frame at this location.
Bytecode:
0000000: 0000 0000 014b 014c 1303 a1b8 03a3 03bd
0000010: 006e 1303 a5b8 03a7 b803 a94d 2cb2 03ab
0000020: a500 3a2c c101 6a99 002b b803 ad13 03ae
0000030: b803 b013 03b1 b803 b3a7 0007 b803 b5bf
0000040: 01b6 03b7 b603 b901 b603 bbc0 0023 4ca7
0000050: 0008 2cc0 0023 4ca7 000b bb00 2359 b703
0000060: bd4c 2bb3 0018 b1
Exception Handler Table:
bci [51, 57] => handler: 60
at java.lang.Class.getDeclaredConstructors0(Native Method)
at java.lang.Class.privateGetDeclaredConstructors(Class.java:2404)
at java.lang.Class.getDeclaredConstructors(Class.java:1853)
at org.mockito.internal.creation.jmock.ClassImposterizer.setConstructorsAccessible(ClassImposterizer.java:75)
at org.mockito.internal.creation.jmock.ClassImposterizer.imposterise(ClassImposterizer.java:70)
at org.powermock.api.mockito.internal.mockcreation.MockCreator.createMethodInvocationControl(MockCreator.java:110)
at org.powermock.api.mockito.internal.mockcreation.MockCreator.mock(MockCreator.java:60)
at org.powermock.api.mockito.PowerMockito.mockStatic(PowerMockito.java:70)
at com.example.UtilTest.test(UtilTest.java)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
at org.powermock.modules.junit4.rule.PowerMockStatement$1.run(PowerMockRule.java:52)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at org.powermock.reflect.internal.WhiteboxImpl.performMethodInvocation(WhiteboxImpl.java:2014)
at org.powermock.reflect.internal.WhiteboxImpl.doInvokeMethod(WhiteboxImpl.java:885)
at org.powermock.reflect.internal.WhiteboxImpl.invokeMethod(WhiteboxImpl.java:713)
at org.powermock.reflect.Whitebox.invokeMethod(Whitebox.java:401)
at org.powermock.classloading.ClassloaderExecutor.execute(ClassloaderExecutor.java:98)
at org.powermock.classloading.ClassloaderExecutor.execute(ClassloaderExecutor.java:78)
at org.powermock.modules.junit4.rule.PowerMockStatement.evaluate(PowerMockRule.java:49)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
at org.junit.runner.JUnitCore.run(JUnitCore.java:157)
at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:63)
@PrepareForTest(Util.class)
public class UtilTest {
@Rule
public PowerMockRule powerMock = new PowerMockRule();
@Test
public void test() {
mockStatic(Util.class);
...
Env: MacOSX 10.7.5, openjdk-1.7
Deps: powermock-1.5, mockito-1.9.5 and hamcrest-1.3, junit-1.4.10.
Adding -XX:-UseSplitVerifier seems fixes original the issue. But when added to
be used by maven / surefire as:
<plugin>
<artifactId>maven-surefire-plugin</artifactId>
<version>${surefire-plugin.version}</version>
<configuration>
<argLine>-XX:-UseSplitVerifier</argLine>
</configuration>
</plugin>
causes random failures in other not related to powermock unit tests.
Sometimes whole suite of tests even passes with success. But it is not reliable.
Original comment by lystoc...@gmail.com
on 1 Feb 2013 at 1:29
I think you should bring this up on the Javassist issue tracker since it's
looks to me that the issue is with Javassist.
Original comment by johan.ha...@gmail.com
on 1 Feb 2013 at 1:49
Original issue reported on code.google.com by
kurm...@gmail.com
on 6 Nov 2011 at 2:23Attachments: