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

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

　　将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打造为一个平台而非功能较多性解决方案。

　　本文转载自其它媒体，转载目的在于传递更多信息，并不代表本网赞同其观点和对其真实性负责。