Does Java 8 Support Closures?

Why oh why, Java. Why oh why.

You would need to hold a long (private) discussion with the relevant Oracle Java team members for the true answer. (If they would be willing to talk to you ...)

But I suspect it is a combination of backwards compatibility and project resourcing constraints. And the fact that the current approach is "good enough" from a pragmatic perspective.

Implementing procedure contexts as first-class objects (i.e. closures) requires that the lifetime of certain local variables extends beyond the return of the declaring method call. That means that you cannot just put them on the stack. Instead you end up with a situation where some local variables have to be fields of an heap object. That means you need a new kind of hidden class OR fundamental changes to the JVM architecture.

While it is technically possible to implement this kind of thing, the Java language is not a "green field" language. A change of the nature that would needed to support "real closures" in Java would be difficult:

• It would take a huge amount of effort from Oracle and 3rd party implementors to update all of the tool chains. (And we are not just talking about compilers. There are debuggers, profilers, obfuscators, bytecode engineering frameworks, persistence frameworks ...)

• Then there is the risk that some of these changes would impact on backwards compatibility for the millions of existing deployed Java applications out there.

• There is the potential impact on other languages, etc that leverage the JVM in some way. For example, Android depends on the JVM architecture / bytecode files as the "input language" for its Davlik tool-chain. There are language implementations for Python, Ruby and various functional languages that code generate for the JVM platform.

In short "real closures" in Java would be a big scary proposition for everyone concerned. The "closures for finals" hack is a pragmatic compromise that does work, and that is good enough in practice.

Lastly, there is always the possibility that the final restriction could be removed in a future edition. (I wouldn't hold my breath though ....)

Will android support Java-8 features?

That is impossible to answer unless someone has credible inside knowledge. And if they did, they would be crazy to reveal it here. Certainly Google have not announced support for Java 8.

^{But the good news is that Java 7 syntax extensions are now supported with KitKat and corresponding versions of Android Studio or Eclipse ADT.}

You will have to state your definition of "closure".

To me, a "closure" is something (a function or object or other thing that can be run in some way like having methods) that captures ("closes over") a local variable from its enclosing scope, and which can use that variable in its code, even when the function or object's method is run at a later time, including when the enclosing scope no longer exists. In different languages, it may be possible to capture a variable by value, or by reference, or both.

By this definition, Java anonymous classes (which have been there since Java 1.1) are closures, since they can refer to local variables from its enclosing scope.

Lambdas in Java 8 are basically a special case of anonymous classes (namely, an anonymous class which implements an interface with exactly one method (a "functional interface"), and which has no instance variables, and which does not refer to itself (using this explicitly or implicitly)). Any lambda can be re-written into an equivalent anonymous class expression. So what is said above also apply to lambdas.

That's uh, not a closure I think.

Well, you sir, have a messed up definition of "closure".