these refactorings are not adding much value, so closing the request, thanks.

Actually, it can.

• Lambdas and anonymous classes are not compiled into the same bytecode. See [http://blog.takipi.com/compiling-lambda-expressions-scala-vs-java-8/].
• Furthermore, lambdas are usually easier to read.

I think the PR raise the question regarding the adoption of the lambda syntax throughout the whole project. As a potential contributor, I would be interested by the project's maintainers on this.

Thanks Hugues.

I have seen a pull request where @mperry asking to use java 8 lambda instead of anonymous class. Not sure if we want to do it project wide.

In #64 , @mperry wrote

Please use lambdas in your code (rather than anonymous inner classes). The old code has not been updated to use them, but we should be using them in new code.

I think we should use lambda expressions throughout the project.

We are using the Retrolambda project to backport lambda expressions to Java 7 bytecode (https://github.com/orfjackal/retrolambda). Retrolambda does has a potential risk under known limitations:

"May break if a future JDK 8 build stops generating a new class for each invokedynamic call. Retrolambda works so that it captures the bytecode that java.lang.invoke.LambdaMetafactory generates dynamically, so optimizations to that mechanism may break Retrolambda."

It would be nice if someone went through to change existing methods to use lambdas.

Is it necessary to put parenthesis around one argument function parameter lists, e.g.

static public <A, B, C> F<C, B> o(final F<A, B> f, final F<C, A> g) { return (c) -> f.f(g.f(c)); }

instead of c -> f.f(g.f(c));

It would be nice if someone went through to change existing methods to
use lambdas.

Intellij could probably do it all in one go.

@techtangents IntelliJ is a good idea, but has to be very careful when refactoring in IntelliJ, it is not safe enough :)

@mperry : c -> f.f(g.f(c)); looks better. parenthesis are unnecessary. will update. Thanks

@mperry Could you please review this PR?

@amarpotghan I will have a look.

Overall comment: I think these changes can be merged as is, but they would be better if we changed some of the code to use the static constructors where applicable to take advantage of type inference.

@amarpotghan Thank you for your changes. Can you update the PR to reflect my comments?

@mperry thanks for the feedback, will update the PR soon.

@mperry Suggested changes are accommodated . please let me know in case I have missed anything

Thanks for making those changes @amarpotghan. I will merge the PR now.

That is quite an effort to chase up all those lambdas. Did you get every single one or do you think there are more to do?

@mperry I did not chase every single :). There are quite a few still remaining to replace. They can be replaces while and when we touch the code there!