java语言的演化——读JavaOne ppt笔记

    JavaOne2008上有个session《Upcoming Java Programming Language Features》，讲了即将到来的jdk7可能引入的新的语言特性，比较开眼界的是jsr308对Annotation的扩展使用，更多地作为断言或者 说checker使用以便减少bug。在ppt前面，我觉的更有意思的是对java语言演化的讲述，做个笔记。

1 、应用 VS. 语言

应用是特性越多越好，应用是 rich 的；而语言是 pure 的，更少的、普通的特性更好。

2 、添加一个 java 语言特性的三个前提：尊重过去、着眼未来以及顾及模型。

无论是增加、减少或者改变一个 feature 都可能 broken 已经存在的代码，一个新增加的 feature 必须兼容已经存在的代码，兼容是个沉重的包袱，就 java 语言而言，我相当认同尊重过去 这一点，哪怕加入闭包这样的特性也不应当以损坏兼容性为代价，更好的选择是将这些特性让 jvm 上的新语言去实现（比如JRuby、Scala）， java 语言作为成熟的工业语言本身不应当做太大的改变。而着眼未来，也就是说新的语言特性应该为未来的语法扩展留有空间，它的语法 / 语义不应当跟现存的或者潜在的特性相冲突，以便可以持续地演化。再谈顾及当前的模型，一门语言代表着一种计算模型，比如 simula 是 OO 模型（ classes) ， Erlang 就是 inter-process communication 的模型 (actor ）。 Java 语言也有一个简单的模型：首先它是“高层”语言，是一门通用、并发、基于类的 OO 语言，其次，它跟 API 、 JVM 有良好的结合。 Java 语言模型有四个原则：

a) 鼓励 high-level 实践，通过抽象来隐藏偶然复杂度。简而言之： do the right thing 。

b) 追求清晰，程序被读的时候远远多于写。简而言之： do the thing right.

c) 青睐静态类型，静态类型能增进对代码的信心，静态类型能证明 bug 在编译时的不存在，而测试和动态类型能证明 bug 的存在。我的观点是，大多数难以寻找和解决的 bug 都是 runtime 的，静态类型在此方面能给出的帮助有限，充分并且适宜的测试更加能增强你对应用的信心。

d) 语言比之 API 的更广泛。 one language,many api 。 API 来去匆匆，而语言却是 forever ，因而将语言和 API 分离是明智的，一些特性可以做为库来实现， jdk5 并发库的引入就很好， jdk7 在并发方面同样将引入 fork/join 模型。

     java语言 的演化也当遵循这四个原则。再看看传说中的闭包语言，当它跟泛型结合的时候写出来的东西还谈得上清晰吗？闭包的实现能否解决兼容性问题也是个疑问。就四个 提案，C3S需要引入method关键字（类似lambda)，FCM的#号看起来比较怪异，在我看来，CICE和BGGA更符合胃口，CICE对 java语言的变动应该最小，学习曲线也比较平缓，BGGA的=>符号更有函数式语言的味道。闭包的引入，某种程度上能减少敲击键盘的次数并实现一 些高阶功能，特别是在聚合操作（如filter、map等）和单抽象方法类（如Runnable,Callable）的使用上，但是在现代IDE的自动化 帮助下，这个带来的价值是值的怀疑的。