Java 8支持关闭？(Does Java 8 Support Closures?)

Java 8支持关闭？(Does Java 8 Support Closures?)

我很困惑。 我认为Java8将从石器时代出现，并开始支持羔羊/闭嘴。 但是当我尝试：

public static void main(String[] args) { int number = 5; ObjectCallback callback = () -> { return (number = number + 1); }; Object result = callback.Callback(); System.out.println(result); }

它说这个number should be effectively final 。 那是呃，不是我想的闭嘴。 这听起来像是通过价值复制环境，而不是参考。

奖金问题！

android会支持Java-8功能吗？

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

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?

最满意答案

为什么哦为什么，Java。 为什么哦为什么

您将需要与相关Oracle Java团队成员进行长时间（私人）的讨论，以获得真实答案。 （如果他们愿意跟你说话...）

---

但我怀疑它是向后兼容性和项目资源限制的组合。 而从现实的角度来看，目前的做法是“够好”的事实。

将过程上下文实现为一级对象（即闭包）要求某些局部变量的生存期延伸到声明方法调用的返回之外。 这意味着你不能把它们放在堆栈上。 相反，您最终会遇到一些局部变量必须是堆对象的字段的情况。 这意味着您需要一种新的隐藏类或对基于JVM架构的基本更改。

虽然在技术上可以实现这种事情，Java语言不是一种“绿色领域”的语言。 改变自然需要支持“真正的关闭”将是困难的：

Oracle和第三方实施者需要花费大量的精力来更新所有的工具链。 （我们不仅仅是编程器，还有调试器，分析器，混淆器，字节码工程框架，持久性框架...）

那么有一些这样的变化会对数百万现有部署的Java应用程序的向后兼容性产生影响。

对其他以某种方式利用JVM的语言等有潜在的影响。 例如，Android依赖于JVM架构/字节码文件作为其Davlik工具链的“输入语言”。 有针对Python，Ruby以及为JVM平台生成的各种功能语言的语言实现。

---

简而言之，Java中的“真正关闭”对于每个人都是一个很大的可怕的主张。 “关闭决赛”黑客是一项务实的妥协，工作正常，实际上足够好。

最后，总是有可能在未来版本中删除final限制。 （我不会抱着我的呼吸....）

---

android会支持Java-8功能吗？

除非有内在知识可信，那是不可能回答的。 如果他们这样做，他们会疯狂地在这里揭示。 当然Google还没有宣布支持Java 8。

^{但是好消息是，现在，Kit7at和相应版本的Android Studio或Eclipse ADT支持Java 7语法扩展。}

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 need to support "real closures" 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.}