Since syntactic sugar has to map to another (more verbose) language feature it cannot offer complete closure support; there are some features of BGGA closures for example that cannot be mapped to anonymous inner classes, and so they couldn't be implemented through this approach。 Nevertheless the idea opens up the possibility of having various new syntaxes for representing anonymous inner classes, similar to BGGA syntax or FCM syntax, and allowing developers to pick the syntax they want to work with。 Other language features, such as the null-safe Elvis operator, could certainly be done this way。 To experiment further with the idea this NetBeans module also developed by Chapman, is what he describes as a "barely functional" prototype for Properties using this approach。

Conclusion

In language development there is always a trade-off between stability and progress。 The advantage that all of these techniques bring is that they don't affect the platform or the language。 In consequence they are more tolerant to mistakes and are therefore more conducive to rapid and radical experimentation。 With developers freely able to experiment we should begin to see more people separately tackling the poor signal to noise ratio of some common boilerplate such as the anonymous inner class syntax, mixing and evolving these ideas to some optimum form that adds the most value in the most cases。 It will be fascinating to see how developers use these different approaches to push the Java platform in new directions。

不改变语言的前提下推进Java演进

James Gosling在“The Feel of Java”中说过：Java是一种蓝领语言，它并不是博士的论文材料而是可以完成工作上的语言。很多不同的程序员都非常熟悉Java，因为我有一种趋势去选择普及的东西，这是一个不错的选择。

Java的这种成功证明了它的这种方法是正确的，如果Java今天仍然以这个为目标，那么它的语言演进将变得很缓慢。Java作为一个成熟，使用广泛的语言也将导致其演进过程充满了困难。一方面，每个特性添加到语言中都有可能造成不可预知到后果，这么做会疏远那些熟悉Java的人，另一方面，本身很完美的特性可能在与其他特性进行交互时产生未知的影响。更糟的是，一旦增加了某个语言特性，几乎就不可能再将它移除，即使这个特性会对整个语言产生危害也没办法。语言设计者为了证明某个特性是正确的，应该从长远的角度来考虑，不应该在短期内解决这个问题，而之后就变成了多余的。为了降低风险，语言设计者一般会创建单独的一种语言或者分支来进行试验，比如Pizza语言就是在完成前用来测试Java泛型的。这种方式的问题在于试验的参与者是比较少的人群，并且是自愿的。他们对语言特性很感兴趣，很多人是学者或者研究员。但是，在普通的程序员使用这些特性时，那些学者或是研究员认为很好的特性可能变得很糟。论文网

为了感受一下这种情况，请考虑Java7闭包特性的激烈争论。很长时间以来有人在提案中给出了闭包的实现，但最终却还是没有达成共识。然后，Sun公司不在JDK7中添加完整的闭包支持。争论的焦点转向为添加泛型会不会导致Java变得越来越复杂，在Java中已经通过匿名内部类部分实现该功能的情况下，完整闭包还是正确的吗。需要完整闭包支持的是简化fork/join API(添加到了JDK7中以改进多核编程)的使用以及清理资源。Josh Bloch的ARM block提案对第二个问题给出了另一种解决方案。Cliff Click博士在面向Java的可扩展，非阻塞变成风格的研究中给出了关于fork/join的另一种方案，这种方案随着核心处理器的不断增加看起来也很合理，如果这种成为可能的话，那么Java中使用闭包的地方将会很少了，语言就不需要提供这个特性了。