想追赶.Net的脚步？Java面前障碍重重

---待到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的迭代步伐已经明显放缓。

Sample features in Java and .Net and their release dates

进展为何如何缓慢？

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

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

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

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

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

Java社区进程的发展为何受阻？问题不在于开放性，而在于利益争夺。尽管当时我是以旁观者的身份看热闹，但仍然清楚记得Sun在参与EJB3项目时遭遇的窘境。为什么Java发展进度会一落千丈？这是由于Sun与甲骨文双方需要将购买或者开发出的产品整合到应用程序服务器当中。一旦新的JavaEE规范出台，他们也必须保证自己能在市场上率先做出反应。

即使是在同一家公司内部，协调好单一产品的发布都绝非易事，更不用说在多家公司之间了。幸运的是，企业合并给事情带来了转机。我一直认为Java社区进程并不是Java进度落后的主要原因。

#p#

将Saucer分离出来

如今，Sun只留存在我们的记忆中，而甲骨文则成为真正的老板。然而为什么Java新版本的发布仍然如此迟缓？最简单的解释是，Java项目规模过于庞大。大项目往往行动缓慢且充满风险。为了解决这个问题，让我们看看如何帮助Java“减肥”。

首先，甲骨文必须克服自身对客户端技术的过分依赖。当然，Swing与甲骨文还拿不出JavaFX的有力继承方案，毕竟在现代Web浏览器上开发出效果相同而又不引发新麻烦的机制绝非易事。不过甲骨文需要将客户牢牢束缚在自己的平台上——至少他们确实是这么做的。

目前我还不清楚JavaFX或者Java的客户端战略能给甲骨文带来哪些真正的优势。看起来甲骨文似乎设计出一种技术，用于同VB6、Flash或者某些4GL方案竞争。在现代BYOD多平台环境下，每位与时俱进的高管人士都希望能在iPad上通过写写划划完成工作。为什么我们要用客户端来束缚服务器的能力？摆脱了客户端，甲骨文很可能不必再面对大量安全延误，并通过告别《Java零日安全漏洞》以及《如何在计算机中禁用Java》等头条为自己争取公关主动性。

不过事实上这种占用了大量资金投入的垂直技术平台应该被直接剔除并宣判其死刑，因为它对于解决主要矛盾根本毫无贡献。甲骨文甚至有可能将其添加到其它灾难性方案中，例如Java ME，并将其命名为Ordroid。如果甲骨文买下黑莓、将其重组为麾下的新部门并打出“未来的平台方案”以及“iPhone终结者”之类的唬人口号，投资者们也只会将其视为虚张声势的愚蠢方案。

简单来说，Java语言对于Java平台已经不再像过去那么重要。另一大负面因素在于，微软的介入削弱了Java的独有性，这种不利局面即使在2007年之后的实践协调活动中也未能得到扭转。对于甲骨文公司来说，将Java语言从Java平台中剥离出来并为其单独规划日程安排会更加轻松——毕竟甲骨文推出的开发工具既不属于Java相关业务中的主要组成部分，也没能得到Java开发人士的广泛支持。微软需要考虑Visual Studio版本是否能与下一代.Net以及C#版本相协调，但甲骨文则不必为此担心。

Java平台支持多种编程语言，从JavaScript到JRuby再到Scala不一而足。此外，以高性能及可扩展方式支持这类不同技术对于云计算非常重要。如果云计算将成为未来的发展方向，那么Java平台与甲骨文都需要提前做好准备。目前，Java与甲骨文已经对这一趋势表示默认。在我们看来，对Ruby、Scala甚至Node.js的广泛支持已经成为Java平台的最大特色。然而正因为如此，目前Java平台更多被视为一种立足根基而非创新引擎。

在为Java平台选择合适的支持语言类型方面，我更信任Charles Nutter（JRuby/红帽）与Martin Odersky（Scala/Typesafe）而非Mark Reinhold（Java SE规范/甲骨文）。我对Reinhold先生绝无丝毫不敬之意，而且已经有证据表明众多协作尝试正在进展当中，不过等待Java语言或其它甲骨文附属项目的发展实在耗去了太多时间。

对于甲骨文在Java领域的领导权来说，这是充满挑战的一年。Sun当初做出的许多决定开始回过头给使用者带来困扰。我给出的答案是放弃Java客户端、将JVM与语言的发布周期分离开来，同时专注于将Java打造为一个平台而非万能性解决方案。

英文原文：http://www.infoworld.com/d/application-development/java-faces-tough-climb-catch-net-224372