lambda - Does Java 8 Support Closures?

Question

I'm confused. I thought Java 8 was going to emerge from the stone age and start supporting lambdas/closures. But when I try this:

public static void main(String[] args) {
    int number = 5;

    ObjectCallback callback = () -> {
        return (number = number + 1);
    };

    Object result = callback.Callback();
    System.out.println(result);
}

...it says that number should be effectively final. That's uh, not a closure I think. That just sounds like it's copying the environment by value, rather than by reference.

Bonus question!

Will Android support Java 8 features?

Answer 1

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.}