在不改变语言的前提下如何推进Java的不断演进

核心提示：James Gosling在“The Feel of Java”中说到：Java是一种蓝领语言，它并非博士的论文素材而是用于完成工作的语言，在不改变语言的前提下如何推进Java的不断演进，各式各样的程序员都非常熟悉Java，因为在设计Java之初我就坚持这样一种观点：选择久经考验的东西而非仅仅是

James Gosling在“The Feel of Java”中说到：

Java是一种蓝领语言，它并非博士的论文素材而是用于完成工作的语言。各式各样的程序员都非常熟悉Java，因为在设计Java之初我就坚持这样一种观点：选择久经考验的东西而非仅仅是听起来很美。

Java所获得的巨大成功证明了这种设计方式是正确的，但如果这依然是当今Java的重要目标的话，那么其结果就是语言的演进将变得非常缓慢。除此以外，Java是一门成熟、使用广泛的语言这个事实也将导致其演进过程充满了困难。一方面，添加到语言中的每个特性都可能在一定程度上造成不可预料的结果，这么做会疏远那些已经使用了该语言的开发者。另一方面，本身很完美的特性可能在同语言中的其他特性进行交互时产生不可预料的结果。更糟的是，一旦增加了某个语言特性，几乎就不可能再将其移除了，即便是该特性会对整个语言产生不利影响也没办法。为了证明某个新特性是正确的，语言设计者必须确信从长远来看，该特性会给语言带来好处，而不是短期效益或是针对某个问题的快速解决方案，之后就变得可有可无了。为了降低风险，语言设计者通常都会创建单独的一种语言或是分支来进行试验，比如Pizza语言就是在实现前用来测试Java泛型的。这种方式的问题在于试验的参与者非常小众并且都是自己想参与进来的；显然他们对语言特性很感兴趣，很多人都是学者或研究员。但是，在普通的程序员开始使用这些特性时，那些学者或是研究员认为很棒的特性可能会变得很糟。

为了直观感受一下这种情况，请考虑关于Java 7闭包特性的激烈争论。一段时间以来，有人在提案中给出了闭包的实现，但最终却还是没有达成共识。随后，Sun决定不打算在JDK 7中添加完整的闭包支持。这时争论的焦点转向为Java是否变得越来越复杂了，在Java 5中添加泛型（尤其是通配符语法）时就已经出现了这种争论；在Java已经通过匿名内部类部分实现该功能的情况下，完整的闭包支持是否是正确的呢。需要完整闭包支持的两个重要场景是简化fork/join API（添加到了JDK 7中以改进多核编程）的使用以及辅助资源的清理。Josh Bloch的ARM block提案（期望通过Project Coin加入到JDK 7中）就第二个问题给出了另一种解决方案。Cliff Click博士在面向Java的可扩展、非阻塞编程风格的研究中给出了关于fork/join的另一种方案，随着处理器核心数的不断增 加，这种方案看起来更合理。如果这一切都成为可能的话，那么Java中使用闭包的地方将变得非常少了，语言根本没必要提供这个特性。