New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cucumber-java8 fails on OpenJDK 1.8.0 #912

Closed
mawis opened this Issue Sep 23, 2015 · 61 comments

Comments

Projects
None yet
@mawis

mawis commented Sep 23, 2015

Cucumber-Java8 depends on internals of the implementation of Oracle's JDK8. When I started experimenting with it I just always got the following exception:

Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.056 sec <<< FAILURE! - in soy.wimmer.CucumberIT
Feature: Cucumber with Java8  Time elapsed: 0.047 sec  <<< ERROR!            
cucumber.runtime.CucumberException: Failed to instantiate class soy.wimmer.CucumberStepdefs
[…]                                                                          
Caused by: java.lang.reflect.InvocationTargetException: null                 
[…]                                                                          
Caused by: cucumber.runtime.CucumberException: java.lang.IllegalArgumentException: Wrong type at constant pool index
[…]                                                                          
Caused by: java.lang.IllegalArgumentException: Wrong type at constant pool index
    at sun.reflect.ConstantPool.getMemberRefInfoAt0(Native Method)           
    at sun.reflect.ConstantPool.getMemberRefInfoAt(ConstantPool.java:47)     
    at cucumber.runtime.java8.ConstantPoolTypeIntrospector.getTypeString(ConstantPoolTypeIntrospector.java:37)
    at cucumber.runtime.java8.ConstantPoolTypeIntrospector.getGenericTypes(ConstantPoolTypeIntrospector.java:27)
    at cucumber.runtime.java.Java8StepDefinition.<init>(Java8StepDefinition.java:45)
    at cucumber.runtime.java.JavaBackend.addStepDefinition(JavaBackend.java:162)
    at cucumber.api.java8.En.Given(En.java:190)                              
    at soy.wimmer.CucumberStepdefs.<init>(CucumberStepdefs.java:8)           
[…]

The test project causing this output is available at https://github.com/mawis/cucumber-java8-test

While it fails on OpenJDK8 it works without problems on Oracle JDK8. I consider this to be a bug, as I don't think that cucumber should depend on a specific implementation of the compiler.

@aslakhellesoy

This comment has been minimized.

Contributor

aslakhellesoy commented Sep 23, 2015

Thanks for reporting this.

Do you have a suggestion for a portable implementation?

@mawis

This comment has been minimized.

mawis commented Sep 23, 2015

Sorry, no. That's to much in the internals of Java for me.

@bofkentucky

This comment has been minimized.

bofkentucky commented Sep 25, 2015

This issue may also be related https://groups.google.com/forum/#!topic/cukes/VMpJPa1xx58 We see the same tests work on Oracle JDK 1.8.0u51 but fail on Oracle JDK 1.8.0u60

@marciomarinho

This comment has been minimized.

marciomarinho commented Sep 29, 2015

I have the same problem. It works fine on Oracle JDK 1.8.0u51 but crashed with that stack trace "Caused by: cucumber.runtime.CucumberException: java.lang.IllegalArgumentException: Wrong type at constant pool index" on Oracle JDK 1.8.0u60.

@dbcowboy

This comment has been minimized.

Contributor

dbcowboy commented Sep 29, 2015

Issue appears to be that different JVMs build the ConstantPool class differently in this method. The code expects to find the desired parameter type at a certain index but that’s not always the case. A quick (but obviously poor) solution is to iterate from the end until locating a valid value and using it. Really just trades one assumption for another; unfortunately I’m not strong with reflection, I'm sure there's a better way to do this.

Here’s my updated version of the ConstantPoolTypeIntrospector.getTypeString() method:

private String getTypeString(ConstantPool constantPool) {
    int size = constantPool.getSize();
    String[] memberRef = null;

    // find last element in constantpool with valid memberRef
    for (int i=size-1; i>-1; i--) {
        try {
            memberRef = constantPool.getMemberRefInfoAt(i);
            break;
        } catch (IllegalArgumentException e) {
            // eat error; null entry in ConstantPool?
        }
    }

    // This assumes the desired value always in same location of constantpool array         
    //  memberRef = constantPool.getMemberRefInfoAt(size - 2);
    return memberRef[2];
}

With this change I'm able to run my code in both Oracle JDK 1.8.0u51 & 1.8.0u60 successfully.

@dkowis

This comment has been minimized.

Member

dkowis commented Sep 29, 2015

IMHO that's a reasonable band-aid. I'd merge a pull request that passes tests for this :) (I don't know if we have a travis build that fails at this point?)

I'd keep another issue open though about making it better.

@aslakhellesoy

This comment has been minimized.

Contributor

aslakhellesoy commented Oct 13, 2015

I haven't been able to reproduce this because I can't easily get my hands on Oracle JDK 1.8.0u60. It's not available for OS X (my laptop) and not on Travis CI. It's not trivial to install your own JDK version on Travis.

Any suggestions how I can reproduce this?

@dbcowboy

This comment has been minimized.

Contributor

dbcowboy commented Oct 13, 2015

My apologies, I have haven't used OS X for a while so this may be dumb question but can you not install the 8u60 Mac OS X x64 dmg from here? http://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-2133151.html

@aslakhellesoy

This comment has been minimized.

Contributor

aslakhellesoy commented Oct 13, 2015

@dbcowboy you're probably right! I've been relying too much on automatic updates. I can try that.

Thanks!

@pablobcb

This comment has been minimized.

pablobcb commented Oct 20, 2015

@dbcowboy, how am i supposed to replicate this patch?

@dbcowboy

This comment has been minimized.

Contributor

dbcowboy commented Oct 21, 2015

Issue can be observed by first ensuring Oracle JDK 1.8.0u51 or earlier used to execute mvn test for cucumber-jvm/java8/pom.xml; observe all tests run as expected. Next ensure JDK 1.8.0u60 used for same operation; observe IllegalArgumentException error for LambdaStepDefs.

Update source with pull request #914

Repeat tests with each JDK; no error occurs.

Very interested in @atorstling proposed changes for #924 as may be more robust solution.

@markwinspear

This comment has been minimized.

markwinspear commented Oct 27, 2015

Is the pull request above being progressed? It would be nice to get some tests running again on later versions of JDK

Incidentally, I've gone back to using 1.8.0u45 and noticed that the same error is encountered replacing the lambda with a method reference [2]:

[1] This fails on later JDKs as we know, but works on u45...
When("^logging in as an admin$", () -> {
login.loginAsAdmin();
});

[2] Replace lambda with a method reference and use u45
When("^logging in as an admin$", login::loginAsAdmin);

@aslakhellesoy

This comment has been minimized.

Contributor

aslakhellesoy commented Oct 27, 2015

It seems both #914 and #924 fix this issue. I'm investigating and considering applying both of them. Hold tight.

@kozhevnikov

This comment has been minimized.

Member

kozhevnikov commented Nov 4, 2015

FYI JetBrains just release IntelliJ 15 which changes default new steps file autogenerating from annotated to lambda-based syntax (given the Java 8 project and/or Maven dependancy I presume), so a lot of new people will be hit by this right out of the gate (me included with OS X and Oracle's JDK 8u66).

@raner

This comment has been minimized.

raner commented Nov 4, 2015

I'm running into the same problem on Mac OS X 10.11.1 with Oracle's JDK 1.8.0u65...
Any progress on this issue or a known work-around?

@aslakhellesoy

This comment has been minimized.

Contributor

aslakhellesoy commented Nov 4, 2015

I'm about to disappear for 6 weeks. Maybe @brasmusson can help in the meanwhile.

@RichardBradley

This comment has been minimized.

Contributor

RichardBradley commented Nov 9, 2015

(I have encountered the same problem, using Oracle JDK 1.8.0u60 on Windows)

@fixl

This comment has been minimized.

fixl commented Nov 12, 2015

We're facing the same problem with Oracle JDK 1.8.0_60 on Windows and Cucumber 1.2.4

aslakhellesoy added a commit that referenced this issue Nov 14, 2015

@schuchert

This comment has been minimized.

schuchert commented Nov 15, 2015

I'm one of those unfortunate just-upgraded to Idea 15 CE.

Sure you know this, it happens in 1.2.4 and 1.2.3

I'm going to experiment. I have a Ubuntu VM I'll stand up with Java 8 and Idea 14 to see if the problem persists. I'll add Idea 15 to see if I can replicate.

Assuming I can, the VM def uses chef/vagrant and it's a public repo on git up. If you want a link to it, let me know. At least you'll be able to reproduce. Get back in a bit if I can reproduce in that environment.

@schuchert

This comment has been minimized.

schuchert commented Nov 15, 2015

Previous problem was Windows 10, Idea 15, Java 1.8 u60.

Next, Ubuntu 15.04, Java 1.8 u40, Idea 14.1.4. Same project works fine.

Installed and ran Idea 15. Reopened project (failed to open project as is, so reopened pom) and it also ran fine.

Upgraded to U66 on Windows Fails in what appears to be the same way as with U60.

@schuchert

This comment has been minimized.

schuchert commented Nov 15, 2015

Final comment of the night. Updated the java cookbook so I now download u65. Idea 14.1.4 + Java 1.8 u65 fails.

Clone this repo: https://github.com/schuchert/vagrant_java. Readme has details. This gives you a VM you an use on your mac (or pc or even other Unix distro) that will fail reliably.

@Eywa-Platform

This comment has been minimized.

Eywa-Platform commented Nov 17, 2015

I confirm for Fedora 22 x64 Java 8 SDK Oracle 66
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO]
[INFO] Cucumber-JVM ....................................... SUCCESS [ 0.771 s]
[INFO] Cucumber-JVM: Core ................................. SUCCESS [ 9.952 s]
[INFO] Cucumber-JVM: JUnit ................................ SUCCESS [ 1.373 s]
[INFO] Cucumber-JVM: Java ................................. SUCCESS [ 8.765 s]
[INFO] Cucumber-JVM: TestNG ............................... SUCCESS [ 1.870 s]
[INFO] Cucumber-JVM: Java8 ................................ FAILURE [ 10.614 s]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 34.317 s
[INFO] Finished at: 2015-11-16T20:10:35-05:00
[INFO] Final Memory: 60M/417M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:2.17:test (default-test) on project cucumber-java8: There are test failures.
[ERROR]
[ERROR] Please refer to /usr/local/share/develop/tools/specs/cucumber-jvm/java8/target/surefire-reports for the individual test results.
[ERROR] -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:2.17:test (default-test) on project cucumber-java8: There are test failures.

Please refer to /usr/local/share/develop/tools/specs/cucumber-jvm/java8/target/surefire-reports for the individual test results.
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:212)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:862)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:286)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:197)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
Caused by: org.apache.maven.plugin.MojoFailureException: There are test failures.

Please refer to /usr/local/share/develop/tools/specs/cucumber-jvm/java8/target/surefire-reports for the individual test results.
at org.apache.maven.plugin.surefire.SurefireHelper.reportExecution(SurefireHelper.java:82)
at org.apache.maven.plugin.surefire.SurefirePlugin.handleSummary(SurefirePlugin.java:195)
at org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:861)
at org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:729)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
... 20 more
[ERROR]
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
[ERROR]
[ERROR] After correcting the problems, you can resume the build with the command
[ERROR] mvn -rf :cucumber-java8

@aslakhellesoy

This comment has been minimized.

Contributor

aslakhellesoy commented Nov 17, 2015

Thank you all. We know it's broken and we know how to reproduce this. No more "me too" comments please. Just be patient, we'll fix this. Please be considerate that I am on leave until mid December.

@RichardBradley

This comment has been minimized.

Contributor

RichardBradley commented Nov 27, 2015

UPDATE: sorry, the "helpful" background I've added here was already discussed up-thread.

This relates to #916, which is another issue caused by the lambda examining reflection being insufficiently generic.

I suppose cucumber-jvm is doing something like the class constant table lookup described at http://stackoverflow.com/a/25613179/8261 , and the class format has changed underneath us.

The obvious fix would be to detect which class file format is in use, but that just extends the hack, rather than really fixing it.

I wonder if there is a more stable way to reflect on Lambdas. Scala seems to manage it pretty well on the JVM, but they have a completely different implementation of Lambdas.
I wonder if a Compiler Annotation Processor might be able to do better here: that happens before some desugaring, doesn't it?

@RichardBradley

This comment has been minimized.

Contributor

RichardBradley commented Nov 30, 2015

I wonder if there is a more stable way to reflect on Lambdas ... a Compiler Annotation Processor might be able to do better here

It does look to me like we could replace the class ConstantPool inspector with a compile-time Compiler Annotation Processor which records the declared generic types.
See e.g. http://stackoverflow.com/questions/29922668/get-typeelement-from-generic-typeparameterelement-for-java-annotation-processor

This would mean that cucumber-jvm would be using a public supported javac API, instead of hacking about with the class files internals (which might change again).

We could either require Cucumber java8 users to annotate their Step files to give cucumber-jvm access to edit the source, or we could do a full project lombok and register a compiler plugin for everyone who compiles anything with cucumber-java8 on the classpath and scan for (and fixup) all calls to En.Given etc.

This might be a bit of a rabbit hole.

Shall I try and code up a proof of concept?

@aslakhellesoy

This comment has been minimized.

Contributor

aslakhellesoy commented Nov 30, 2015

Hi @RichardBradley

It would be fabulous to have a portable implementation. The current one has the following drawbacks/bugs:

  • this bug (not portable across JDK versions)
  • #916
  • #936 - can't get the generic type of List and Map arguments

I haven't worked with annotation processors or compiler plugins, so I'm unaware of what you can do with them and what the pros and cons are.

But I (and everyone using Cucumber with Java8) would be very grateful if you make a PoC and help us fix this!

@RichardBradley

This comment has been minimized.

Contributor

RichardBradley commented Nov 30, 2015

OK, no promises, but I'll have a go :-)
I would also push ahead with the current fix for now, as I don't know if this will work or when it will be ready.

I'll track this at #937 so as not to clutter this issue.

@codependent

This comment has been minimized.

codependent commented Mar 4, 2016

Any update about this issue? Just tested with Oracle's JDK 1.8.0u74 and the same error shows up.

@aslakhellesoy

This comment has been minimized.

Contributor

aslakhellesoy commented Mar 4, 2016

Sorry for the delay folks - I've been snowed under. It's still on top of my priority list of bugs to fix. Just need to set aside a day or two to fix this properly and make a new release.

I believe I have all the info I need to fix this - just need the time.

I'm closing this issue for comments for now.

@dkowis

This comment has been minimized.

Member

dkowis commented May 11, 2016

I'm stupid and only checked Oracle JDK u92 doesn't have any problems. Lemme try OpenJDK

@cucumber cucumber unlocked this conversation Jul 31, 2016

@brasmusson

This comment has been minimized.

Contributor

brasmusson commented Jul 31, 2016

Closed by c1fd8b1.

@Grief

This comment has been minimized.

Grief commented Aug 2, 2016

Hi @brasmusson ,
Are you going to push 1.2.5 to maven central repo in near future?

http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22info.cukes%22%20AND%20a%3A%22cucumber-java8%22

@brasmusson

This comment has been minimized.

Contributor

brasmusson commented Aug 2, 2016

@Grief Hopefully a 1.2.5-version will not have to wait to far into the future, but #1034 is better fixed before that. Until then the latest build on the master is available as a snapshot release.

@erran-r7

This comment has been minimized.

erran-r7 commented Nov 10, 2016

A colleague @kprzerwa-r7 and I encountered this without being sure whether it was ever released. For the next person who stumbles across this issue it was fixed in 96d1e85 (which was released in 1.2.5).

[Java8] Fix IllegalArgumentException on JDK 1.8.0_60 (#912, #914 Michael Wilkerson)

@mpkorstanje

This comment has been minimized.

Contributor

mpkorstanje commented Nov 10, 2016

The documentation at https://cucumber.io/ is still referencing 1.2.4 which contains the bug.

@heshamMassoud

This comment has been minimized.

heshamMassoud commented Mar 13, 2017

@mpkorstanje Seems that doc correctly references 1.2.5 https://cucumber.io/docs/reference/jvm#java

@mpkorstanje

This comment has been minimized.

Contributor

mpkorstanje commented Mar 13, 2017

Excellent! Then it has been fixed.

@zyablic

This comment has been minimized.

zyablic commented May 22, 2017

Guys, say please, it is possible to use method reference in steps definitions? Like this:

Given("I am on the page (.*)", Navigation::openPage);

mpkorstanje added a commit that referenced this issue Jul 14, 2017

[Java8] Replace ConstantPoolTypeIntrospector with TypeResolver
To determine which argument types a lambda function requires we created a
 ConstantPoolTypeIntrospector. However it has never functioned quite correctly
 (#937, #1140, #957), was prone to breaking (#912, #914) and hasn't been tested
 much (#1048).

It is important to understand that while we will get a properly functioning and
 tested replacement, TypeResolver uses the same ConstantPool and thus has the
 same potential to break. However because TypeResolver is used by a much larger
 audience I expect these problems to be shallow.

Because this change the interface of Java8StepDefinition it made sense to
 refactor all the Java8 related stuff out of cucumber-java. This will make it easier in
 the future to add things like KotlinStepDefintions without creating a separate
 KotlinBackend.

Related issues:
 - #912
 - #914
 - #937
 - #957
 - #1140
 - #1048
 - #1140
 -

mpkorstanje added a commit that referenced this issue Jul 14, 2017

[Java8] Replace ConstantPoolTypeIntrospector with TypeResolver
To determine which argument types a lambda function requires we created a
 ConstantPoolTypeIntrospector. However it has never functioned quite correctly
 (#937, #1140, #957), was prone to breaking (#912, #914) and hasn't been tested
 much (#1048).

It is important to understand that while we will get a properly functioning and
 tested replacement, TypeResolver uses the same ConstantPool and thus has the
 same potential to break. However because TypeResolver is used by a much larger
 audience I expect these problems to be shallow.

Because this change the interface of Java8StepDefinition it made sense to
 refactor all the Java8 related stuff out of cucumber-java. This will make it easier in
 the future to add things like KotlinStepDefintions without creating a separate
 KotlinBackend.

Related issues:
 - #912
 - #914
 - #937
 - #957
 - #1140
 - #1048
 - #1140

mpkorstanje added a commit that referenced this issue Jul 14, 2017

[Java8] Replace ConstantPoolTypeIntrospector with TypeResolver
To determine which argument types a lambda function requires we created a
 ConstantPoolTypeIntrospector. However it has never functioned quite correctly
 (#937, #1140, #957), was prone to breaking (#912, #914) and hasn't been tested
 much (#1048).

It is important to understand that while we will get a properly functioning and
 tested replacement, TypeResolver uses the same ConstantPool and thus has the
 same potential to break. However because TypeResolver is used by a much larger
 audience I expect these problems to be shallow.

Because this change the interface of Java8StepDefinition it made sense to
 refactor all the Java8 related stuff out of cucumber-java. This will make it easier in
 the future to add things like KotlinStepDefintions without creating a separate
 KotlinBackend.

Related issues:
 - #912
 - #914
 - #937
 - #957
 - #1140
 - #1048
 - #1140

mpkorstanje added a commit that referenced this issue Jul 14, 2017

[Java8] Replace ConstantPoolTypeIntrospector with TypeResolver
To determine which argument types a lambda function requires we created a
 ConstantPoolTypeIntrospector. However it has never functioned quite correctly
 (#937, #1140, #957), was prone to breaking (#912, #914) and hasn't been tested
 much (#1048).

It is important to understand that while we will get a properly functioning and
 tested replacement, TypeResolver uses the same ConstantPool and thus has the
 same potential to break. However because TypeResolver is used by a much larger
 audience I expect these problems to be shallow.

Because this change the interface of Java8StepDefinition it made sense to
 refactor all the Java8 related stuff out of cucumber-java. This will make it easier in
 the future to add things like KotlinStepDefintions without creating a separate
 KotlinBackend.

Related issues:
 - #912
 - #914
 - #937
 - #957
 - #1140
 - #1048
 - #1140

Closes #937

mpkorstanje added a commit that referenced this issue Jul 15, 2017

[Java8] Replace ConstantPoolTypeIntrospector with TypeResolver
To determine which argument types a lambda function requires we created a
 ConstantPoolTypeIntrospector. However it has never functioned quite correctly
 (#937, #1140, #957), was prone to breaking (#912, #914) and hasn't been tested
 much (#1048).

It is important to understand that while we will get a properly functioning and
 tested replacement, TypeResolver uses the same ConstantPool and thus has the
 same potential to break. However because TypeResolver is used by a much larger
 audience I expect these problems to be shallow.

Because this change the interface of Java8StepDefinition it made sense to
 refactor all the Java8 related stuff out of cucumber-java. This will make it easier in
 the future to add things like KotlinStepDefintions without creating a separate
 KotlinBackend.

Related issues:
 - #912
 - #914
 - #937
 - #957
 - #1140
 - #1048
 - #1140

Closes #937
Closes #1048

mpkorstanje added a commit that referenced this issue Jul 23, 2017

[Java8] Replace ConstantPoolTypeIntrospector with TypeResolver
To determine which argument types a lambda function requires we created a
 ConstantPoolTypeIntrospector. However it has never functioned quite correctly
 (#937, #1140, #957), was prone to breaking (#912, #914) and hasn't been tested
 much (#1048).

It is important to understand that while we will get a properly functioning and
 tested replacement, TypeResolver uses the same ConstantPool and thus has the
 same potential to break. However because TypeResolver is used by a much larger
 audience I expect these problems to be shallow.

Because this change the interface of Java8StepDefinition it made sense to
 refactor all the Java8 related stuff out of cucumber-java. This will make it easier in
 the future to add things like KotlinStepDefintions without creating a separate
 KotlinBackend.

Related issues:
 - #912
 - #914
 - #937
 - #957
 - #1140
 - #1048
 - #1140

Closes #937
Closes #1048

mpkorstanje added a commit that referenced this issue Jul 29, 2017

[Java8] Replace ConstantPoolTypeIntrospector with TypeResolver
To determine which argument types a lambda function requires we created a
 ConstantPoolTypeIntrospector. However it has never functioned quite correctly
 (#937, #1140, #957), was prone to breaking (#912, #914) and hasn't been tested
 much (#1048).

It is important to understand that while we will get a properly functioning and
 tested replacement, TypeResolver uses the same ConstantPool and thus has the
 same potential to break. However because TypeResolver is used by a much larger
 audience I expect these problems to be shallow.

Because this change the interface of Java8StepDefinition it made sense to
 refactor all the Java8 related stuff out of cucumber-java. This will make it easier in
 the future to add things like KotlinStepDefintions without creating a separate
 KotlinBackend.

Related issues:
 - #912
 - #914
 - #937
 - #957
 - #1140
 - #1048
 - #1140

Closes #937
Closes #1048
@abdelwahebg

This comment has been minimized.

abdelwahebg commented Apr 26, 2018

Any news about this issue problem still occurs with JDK 1.8.0_91
java -version java version "1.8.0_91" Java(TM) SE Runtime Environment (build 1.8.0_91-b14)

@mpkorstanje

This comment has been minimized.

Contributor

mpkorstanje commented Apr 26, 2018

Try upgrading to 2.x. I had another go at it. Note the group id has changed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment