Replace anonymous classes with lambdas

[philwebb]

Whilst looking at the code to asses options for #3 I noticed quite a few anonymous classes that could be replaced with lambdas. If Java 6 compatibility isn't an issue, perhaps these changes will be helpful.

[wilkinsona]

I think this may cause some up-to-date checks to break. Unfortunately, lambdas produce non-deterministic class names at runtime that are unstable from run to run. This prevents Gradle from identifying that the actions haven't changed. There's some more information in Gradle's documentation:

For tracking the implementation of tasks, task actions and nested inputs, Gradle uses the class name and an identifier for the classpath which contains the implementation. There are some situations when Gradle is not able to track the implementation precisely:

• Unknown classloader
  When the classloader which loaded the implementation has not been created by Gradle, the classpath cannot be determined.

• Java lambda
  Java lambda classes are created at runtime with a non-deterministic classname. Therefore, the class name does not identify the implementation of the lambda and changes between different Gradle runs.

When the implementation of a task, task action or a nested input cannot be tracked precisely, Gradle disables any caching for the task. That means that the task will never be up-to-date or loaded from the build cache.

I'd be really nice to keep some of the other structural changes, though.

[philwebb]

Well that's annoying. Would the following change be enough to fix it? Is there a good way to add a test for the up-to-date checks?

[wilkinsona]

Sorry, @philwebb. Looking more closely, I think your original changes may be fine. The problem only applies to Actions that are part of a task's execution. Those that are involved only in its configuration should be fine.

Is there a good way to add a test for the up-to-date checks?

Using TestKit and invoking a task twice, checking that the outcome of the first invocation is success and of the second invocation is up-to-date. Here's one example of a test in Spring Boot's Gradle plugin that does this.

[rwinch]

Thanks for the PR @philwebb. I was under the same impression that lambdas did not work with up to date checking. In hindsight, I think this is only applicable when the lambda is an input or output to the task though.

Perhaps you could switch this back to lambda's and add a test that verifies that rerunning in a new folder, the test is up to date.

[philwebb]

I'll revert the second commit and add a test