Build with retrolambda

[hcoles]

It is not even possible to have java 1.6 compatibility and output 1.5 bytecode with the maven compiler.

Retrolambda would make it possible to remove a lot of boilerplate from the codebase, and use other java >1.5 features.

There are a number of issues that would need to be considered including

• Current strategy for testing against different java versions is to build with them via travis ci. This would have to change.
• Not clear how retrolambda would interact with the maven shade plugin
• Would be easy to introduce a dependency on part of the java api above the minimum targeted version

[hcoles]

The combination of retrolambda and the shade plugin do not seem to work currently (shade 2.3, retrolambda 1.8.1).

Not clear that java 8 support is fully there for shade and retrolambda looks to generate invalid (at least as far as ASM is concerned) bytecode.

[tomasz-luch-payu-gpo]

Maybe if you want to keep support for java versions below 8 you could just use Guava? This way you can get rid off a lot of functional code you implemented. In the future you should think about leaving only support for java 8. Some big release.

[hcoles]

The problem with introducing a third party library (particularly something as common as guava) is that the pitest code needs to be active in the same jvm as the code under test.

If the code under test uses a different version of the same library problems occur.

Where pitest has used third party libraries (e.g ASM) it has relocated them to a different package with the shade plugin. This breaks some libraries, would cause licence problems if done for others and is generally a pain.

Not all of the pitest code actually needs to be active in the same jvm, so it ought to be possible to re-structure the code so that code that has this constraint is separate from the rest (which could then introduce 3rd party dependencies).

Unfortunately at the moment the mutation engine does need to be active in the same jvm, so the benefit of restructuring in this way would be slight.

One possible route to clean things up would be -

• Change design so mutants are described as a binary diff so mutation engine would no longer need to share jvm with the SUT.
• Separate code that must share jvm into new module(s)
• Introduce guava/functional java/scala into the rest of codebase

[maxgabut]

The minimum java version is now java 8, so there is no need for this anymore.