【IT168 评论】待到Java 8面世之时，.Net的进度时钟恐怕已经又走过了两到五年——届时微软做出的调整将使二者差距进一步拉大。

　　就在几周之前，我详细介绍了Java 8中值得期待的几大主要功能。不过当时我并没有提到.Net的新变化，事实上Java 8中的大部分(甚至全部)功能都能在.Net中找到。更夸张的是，不少将被推迟到Java 9中实现的功能也将在.Net中出现。我并不赞成将一切功能盲目塞进Java语言的激进行为，不过我认为Java平台(相对于语言本身)确实应该在功能多样性方面下点功夫。在我看来，.Net技术堪称杰出，C#与.Net平台自Java 3时代就开始在各个方面迎头赶上。就个人而言，我对微软的操作系统非常抵触，而且很担心无法修复讨厌的bug(至少在理论上不行)。

　　两套平台、一个故事

　　很多朋友认为微软公司在提供较小安装基础与激发开发者拥护热情方面行动更快，这样的论断还算公正。我还记得上世纪九十年代与两千年初时，微软公司决定以几乎每周一次的速度变更数据库API，于是ODBC、RDO、ADO乃至OLEDB等等一下子涌到我们面前。然而随着.Net的出现，微软的研发强度达到了临界值，后续而来的是更凶猛、更频繁的发展进程。

　　然而Java为什么会落后如此之多?在Java出现的早期，其发展速度同样令人赞叹。从Java 1.0.2到Java 1.1，我们仅在一年之间就迎来了众多根本性(通常也意味着存在兼容性问题)改变。其后，从1.1版本到1.2版本用了一年半时间，之后的1.22——一个看似小更新、实为大升级的版本——仅在七个月后就火热出炉。短短十个月后，里程碑式的Java 1.3版本整装待发，这也是第一个考虑在服务器端加入垃圾收集功能的版本。

　　Java 1.4给我们带来了NIO(即网络接口对象)与正则表达式，与前代版本相隔不到两年。Java 1.4.2则在多核环境中实现了垃圾收集功能(虽然还不太稳定)，开发周期为一年。接下来是Java 1.5，这个开发周期超过一年的新版本将并发一致性GC引入生产流程，并且加入了其它一些重要的并发及NIO功能。

　　Java 1.6将关注重点放在性能节约方面，虽然效果还算显著，但其改进幅度仍然无法与1.5版本相提并论、更遑论用去了无数开发者两年的等待时间。Java 1.7是自1.4.2以来第一个针对底层虚拟机技术(G1 collector)做出大幅改动的新版本，利用invokedynamic指令帮助我们在JVM环境下更好地与其它语言对接。尽管属于大版本升级，但五年的更新周期无疑标志着Java的迭代步伐已经明显放缓。

　　进展为何如何缓慢?

　　我们可以这样来简单解释Java的逐渐落后：Sun本来就不是一家运转状况良好的企业。Java诞生之初互联网正迅速兴起，Sun公司也将运营重点放在了销售Sparc及相关产品方面。与此同时，英特尔与AMD产品的价格逐步下降，Sparc的价格却未作调整。尽管T1000及之后平台的陆续出现令人兴奋不已，但却始终未能形成规模经济、从而将成本缩减到理想范围(没错，最后一款Sparc执行效率更高，但价格却贵得离谱;尽管政府当局要求能耗过高的用户为碳排放过量状况付费，但即便如此最终的总体成本也远低于Sparc给数据中心带来的硬件支出)。

　　互联网经济的泡沫最终烟消云散，Sun公司决定将手中已经建成的大型设备集群转化为“商业化”计算硬件业务。总而言之，Sun在硬件业务方面押下了错误的赌注。

　　Sun所创造出的生态系统堪称伟大，他们只是未能建立起真正符合企业需求、能够激发用户购买欲望的产品。作为Sun成果的最终持有者，甲骨文充分燃尽了生态系统中的每一分潜力，蚕食或者毁灭掉与之相关的一切其它企业，从而创造出仅属于自己的高利润替代产品。

　　甲骨文在一份典型的简要公开声明中，承认某些业务及政治问题拖延了Java 7的发布进度。“众所周知，由于各种业务及政治问题的影响，最新版本的推出被迫延期。”

　　不过我们必须突破Sun的财务难题，继续将关注重点放在Java周边系统身上。Sun出尔反尔地公布了Java标准化计划，并创造出属于自己的“标准化”委员会，即Java社区进程组织。该组织最初的建立目的在于为实力雄厚的Java参与者们打造一个共商大事的平台，而且随着时间的推移其发展也逐渐步入正轨。然而如今Sun已经成为甲骨文毋庸置疑的附属，后者则直接忽略掉委员会的各种规则、粗暴行使着自己的一票否决权。