早在甲骨文收购Sun的协议发布之初，就有业界人士开始对Java语言的命运感到不妙。事实上，这绝非杞人忧天。其中的原因很简单，以甲骨文的强势作风，必然招至其他大型公司防御性的反击。而在这个过程中，受伤的就极可能是Java语言。
业界的反击
也许是甲骨文74亿美元收购Sun公司的光环过于耀眼，以至于没人能注意到Vmware公司同样做出了大手笔的收购，斥资4.2亿美元收购了开源公司SpringSource。
SpringSource是一家已成立5年的公司，拥有活跃的开源开发者社区，以及一些大公司客户。业界人士认为，收购SpringSource使VMware站在了一些关键领域的前沿。SpringSource的Spring Framework支持一半的企业Java项目，该公司同时为广泛使用的Java应用服务器Apache Tomcat提供超过95%的漏洞修复工作。SpringSource还拥有Hyperic应用监控工具。事实上，Vmware的这一步棋确实是瞄向了Java。
近日，VMware公司宣布，将与谷歌展开一系列技术合作，共同交付解决方案。谷歌则宣布支持基于Google App Engine的Spring Java应用。VMware与谷歌合作的结果，就是将下一代应用程序快速开发工具——Spring RooGoogle Web Toolkit(GWT)相结合，用以构建浏览器应用。
在这个过程中，Java作为***开发语言，Java开源框架Spring被当做了***的开发模型。以VMware公司和谷歌公司的影响力来看，未来云计算的半壁江山都有依靠Java+Spring来打拼了。
但是，问题也恰恰出在这个地方。原因就在于Google虽然是一个开源以及开放网络标准的坚定支持者，但却不是Java语言标准的彻底支持者。它不会支持全部的Java标准，而只是支持了一部分。这点突出体现在它的Android平台上，只支持Java基本语法和部分API，并且必须采用Android特有的架构模式。Android平台上的Java程序只是与标准Java程序在源代码级别兼容，编译结果根本不一样，这导致Java的***特点，也就是一次编译到处运行成为空话。而也正是因为这一点，Linux基金会才被迫寻找Android平台的替代品，由Intel和诺基亚支持的MeeGo平台也才会这么快地脱颖而出。
而我们再来审视这一组合，SpringSource属于VMware，谷歌对Java只是部分支持，这二者的组合，实际上就是在云计算这个眼下大热门应用领域，给Java语言的标准另设了一个交集。
沦为牺牲品的可能
在计算机领域，人们越来越明白一个道理的正确性，这就是“非开放系统一定会走下坡路”。但眼下，Java的开放性却正随着私有化而变得越来越低。
也许有人会对这句话表示怀疑，并举出iPhone的例子来，但数据证明了一切。在2009年第三季度之前，iPhone一直在吞食着RIM(黑莓)的市场，但是过了2009年第三季度之后，Andriod突然发力，到了2010年***季度，Andriod已经快速超越iPhone。
也许还会有人忽视标准对Java语言的作用。但把时光往前翻十几年看看吧。微软为了跟Sun争夺Java的事实标准权，开发了自己特有的版本Visual J++，并与其Visual Studio系列开发套件结合在一起，还提供了专有的扩展API。这一系列行为都背离了Sun对于Java规范的要求。这一纷争导致Sun与微软最终对簿公堂。这场纷争最终在2001年以SUN胜出而结束，这也让微软彻底离开了Java阵营。这以后，微软后来创建的.Net体系，多年来一直是Java的强劲对手。这场纷争事实上延续到了今天，前不久51CTO还向大家推荐过“权威测试结果：Java不如.NET安全？”。
但这场纷争也使得Java转变了发展轨迹。JCP组织的成立，允许更多的厂商参与到Java的规范制定当中，最终IBM、甲骨文等众多软件厂商有机会参与到Java的发展当中，这使得Java获得了强劲的发展动力。
事实上，此前业界人士对Java命运的担心正是集中在Java标准之上。Java不是由哪一家厂商可以驱动和一手控制的，过去的成功都是源于社区的广泛支持，JCP在这其中起的作用不容小觑。但现在JCP的效率却越来越受到诟病，原因在于有有许多的技术都是在JCP过程外产生，后来才被集成到Java平台中的，而JCP内部很少培育出像样的技术。
这样，甲骨文可能也会面临一个选择，这就是解散JCP，由自己全权掌控Java。而这样一来，新的Java技术的产生效率就会大大提升。但由此带来的负面影响，正是甲骨文过度控制，Java的标准纷争将因此而起。
由此看来，在内因和外在条件的共同作用之下，Java因私有化而沦为牺牲品的可能性，并非不存在。
【编辑推荐】
