There are quite a few complications of Java lambdas and their abstraction bleeds out in several edge cases. This is a result of their class implementation and would not exist if functions had first class support in the language and barcode bytecode (there are complications there too because they didn't want to change anything at the bytecode level for lambdas).
Lambdas in Java aren't really that complicated. If you understand anonymous classes, you understand lambdas.
That article just compares Java's closures with Javascript's closures. The "limitation" is that Java's closures can only access the final variables of the enclosing scope. But the article agrees that this limitation "can be considered negligible" (seriously, read it-- that's the conclusion.)
Also, starting in Java 8, you don't have to explicitly declare things "final" to use them in anonymous classes or lambdas. They just have to be effectively final, meaning they are not mutated.
> But the article agrees that this limitation "can be considered negligible" (seriously, read it-- that's the conclusion.)
Working both in Java and Lisp professionally, it sure as hell isn't negligible. It changes the way you write code. Lambdas in Java are 80% solution. Java 8 really did make this language finally bearable, sometimes pleasant to work with. 80% solutions are good, but the remaining 20% is not "negligible".
https://dzone.com/articles/java-8-lambas-limitations-closure...