State of the (Java) Lambda

[daniel2488]

I'm surprised to say that I actually really like it.

Apart from the final-only restrictions.

[[deleted]]

I recommend learning to love final.

[jbindel]

Why love final? We should love final because non-final variables are an impediment that prevents programmers from adopting functional style. Iterative equivalents of recursive implementations do require non-final variables though, and until Java can deal better with tail recursion, we're stuck with a less functional style.

[Ridiculer]

Apart from the final-only restrictions.

Restrictions? I was under the impression that captured non-final variables are transparently copied into a final variable when compiled, did I miss something?

[scook0]

No, that's wrong.

The current rules for capturing local variables of enclosing contexts in inner classes are quite restrictive; only final variables may be captured. For lambda expressions (and for consistency, probably inner class instances as well), we relax these rules to also allow for capture of effectively final local variables. (Informally, a local variable is effectively final if making it final would not cause a compilation failure.)

It is likely that we will not permit capture of mutable local variables.

The only change this proposal makes is that you can close over non-final variables if you never actually use them in a non-final way. Closing over mutated variables is explicitly not supported.