Rename java8 to lambda

[aslakhellesoy]

Now that java13 is around the corner it's misleading to use java8. What's special about this module is that it uses lambdas. The JDK version that introduced lambdas is irrelevant.

[mpkorstanje]

Agree! Lets do this for v5! We're breaking things right now.

[mpkorstanje]

Okay. This will be a bit more complicated. I had every body move io.cucumber.java8 in v4. We'll have to do this with a nice migration step.

[mpkorstanje]

So a rough plan:

In v n.x.x

1 . Create a cucumber-lambda module containing all implementation code and generated classes in io.cucumber.lambda.
2. Add a dependency on cucumber-lambda to cucumber-java8 cucumber-lambda.
3. Remove everything but the generated classes and io.cucumber.java8.Scenario.
4. Mark what remains as deprecated.

In v (n+1).0.0

1. Remove cucumber-java8.

It's preferable to do this once we feel we're done with v5. So I'm also considering delaying this until v6 or even later if we can combine it with another breaking change that we might schedule for v7. Just to keep some stability for end user.

[aslakhellesoy]

Good plan @mpkorstanje!

[mpkorstanje]

I am considering holding this off a bit longer (so after v6 or even later).

Type detection in cucumber-java8 depends on typetools. Type tools was introduced as a replacement for our own constant pool hacking. However it also uses the constant pool. Its just much better at it.

The constant pool is part of Javas internal API. This access will eventually be removed. There will be replacement APIs but it remains to be seen if typetools will be updated to use these.

Depending on how this plays out we will have to make a decision. Having a new module name may be an advantage we can use to smooth out the migration.

So either:

1. Access to the constant pool is removed. Type tools is updated (either by us, jhalterman or some one else). We can continue as planned.

2. Access to the constant pool is removed and type tools is not updated. We pin Cucumber Java8 to a specific JVM version, deprecate type dependent code paths and continue the module as Cucumber Lamda with reduced functionality.

   This will allow for an extended period of migration. One that will be much needed. Automatic type conversion is a major productivity advantage but also hard to migrate out of.

Personally I would prefer option 1 but I would like to have the freedom to go with option 2. We may not be in a position to update type tools ourselves in the future.

[mpkorstanje]

See: #1817

[mpkorstanje]

Superseded by: #2174