Looks like it's related to #912 #929 #937 #949 #998 et al. - got no glue what is going on except that reflection is hunting us.
Now that we've got rid of IllegalArgumentException, next one along the road is AbstractMethodError.
Code being called is (StepDefinitions.java):
Given("^foo$", () -> { /* .. */ });
Stacktrace:
cucumber.runtime.CucumberException: Failed to instantiate class oktesting.app.StepDefinitions
at cucumber.runtime.java.DefaultJavaObjectFactory.cacheNewInstance(DefaultJavaObjectFactory.java:47)
at cucumber.runtime.java.DefaultJavaObjectFactory.getInstance(DefaultJavaObjectFactory.java:33)
at cucumber.runtime.java.JavaBackend.buildWorld(JavaBackend.java:131)
at cucumber.runtime.Runtime.buildBackendWorlds(Runtime.java:141)
at cucumber.runtime.model.CucumberScenario.run(CucumberScenario.java:38)
at cucumber.runtime.junit.ExecutionUnitRunner.run(ExecutionUnitRunner.java:102)
at cucumber.runtime.junit.FeatureRunner.runChild(FeatureRunner.java:63)
at cucumber.runtime.junit.FeatureRunner.runChild(FeatureRunner.java:18)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at cucumber.runtime.junit.FeatureRunner.run(FeatureRunner.java:70)
at cucumber.api.junit.Cucumber.runChild(Cucumber.java:95)
at cucumber.api.junit.Cucumber.runChild(Cucumber.java:38)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at cucumber.api.junit.Cucumber.run(Cucumber.java:100)
...
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
at cucumber.runtime.java.DefaultJavaObjectFactory.cacheNewInstance(DefaultJavaObjectFactory.java:41)
... 51 more
Caused by: java.lang.AbstractMethodError: cucumber.runtime.java8.ConstantPoolTypeIntrospector.getGenericTypes(Ljava/lang/Class;)[Ljava/lang/reflect/Type;
at cucumber.runtime.java.Java8StepDefinition.<init>(Java8StepDefinition.java:47)
at cucumber.runtime.java.JavaBackend.addStepDefinition(JavaBackend.java:162)
at cucumber.api.java8.En.Given(En.java:190)
at oktesting.app.StepDefinitions.<init>(StepDefinitions.java:18)
Version info:
------------------------------------------------------------
Gradle 2.6
------------------------------------------------------------
Build time: 2015-08-10 13:15:06 UTC
Build number: none
Revision: 233bbf8e47c82f72cb898b3e0a96b85d0aad166e
Groovy: 2.3.10
Ant: Apache Ant(TM) version 1.9.3 compiled on December 23 2013
JVM: 1.8.0_92 (Oracle Corporation 25.92-b14)
OS: Mac OS X 10.10.5 x86_64
Build file build.gradle
dependencies {
testCompile 'junit:junit:4.12'
testCompile 'org.assertj:assertj-core:3.5.2'
testCompile 'info.cukes:cucumber-java8:1.2.5-SNAPSHOT'
testCompile 'info.cukes:cucumber-junit:1.2.5-SNAPSHOT'
}
I have exactly the same issue with Oracle JDK 1.8.0_101
The Travis build command we used to build and deploy snapshots (mvn -q deploy <...> -DdeployAtEnd=true) seems to have stopped deploying a couple of months ago. Therefore was Java8 the only module to be deployed to Sonatype when I merged the Java8-fixes a couple of days ago (the Java8 module is build and deployed from a separate Travis job, and have used different commands to build all modules, but only deploy the Java8 module).
Since the Java and Java8 modules on Sonatype were of inconsistent versions, the AbstractMethodError makes sense perfectly. Now I have fixed the Travis configuration and have made sure that snapshots of all modules have been updated to the Sonatype repository.
@brasmusson glad to hear that you've sorted this issue out! I tried to find the clue in the sources by myself but failed and now I see that it even wasn't in sources. Today I was trying to upgrade our test code with java 8 style but failed. I'm excited how fast it was fixed and tomorrow I'll do a second try. Also, I suppose nothing is blocking you from publishing 1.2.5 to maven central, right?
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
Most helpful comment
The Travis build command we used to build and deploy snapshots (
mvn -q deploy <...> -DdeployAtEnd=true) seems to have stopped deploying a couple of months ago. Therefore was Java8 the only module to be deployed to Sonatype when I merged the Java8-fixes a couple of days ago (the Java8 module is build and deployed from a separate Travis job, and have used different commands to build all modules, but only deploy the Java8 module).Since the Java and Java8 modules on Sonatype were of inconsistent versions, the
AbstractMethodErrormakes sense perfectly. Now I have fixed the Travis configuration and have made sure that snapshots of all modules have been updated to the Sonatype repository.