【IT168 评论】当初收益Sun公司的决定可以说喜忧参半：甲骨文借此完成转型，从原本的低成本高利润软件业务销售者变身成高成本、低利润硬件业务销售者，而这一切的罪魁祸首正是云时代的全面来临。这一点当然也引起了各投资方的高度警觉。然而投资方们还没有意识到的是：甲骨文一直没能充分发挥Sun技术遗产中的重要价值。
Java代表的是一场重大的发展机遇。Java是Sun公司最得意的作品也是最辉煌的成就。如果Sun能够把硬件业务整体出让给富士通，建立起一套切实有效的销售团队并雇佣一批会做算术的市场营销人员(Java的1.x系列版本，其中1.2可以作为2.0、1.3可以作为2.0，后续的1.4、1.5、6、7都可以作为2.0并卖个好价钱)，那么我的朋友Simon Phipps可能早就已经买下自己的小岛宣布退休，而Sun则仍能屹立在IT技术之林。
甲骨文收购Sun时，后者的糟糕运营已经体现在了Java 7身上，他们似乎再花一百年也拿不出一套完善且能够发布的最终版本——其配套功能也相当有限。甲骨文接手之初许下承诺，宣布将努力制定出具备可操作性的发布计划(好主意)。然而现实总是无情的，甲骨文没能实现Sun当初将Java转为开源的半失败尝试——尽管有点马后炮，但如果这项计划真能变成现实，那么行业会对其张开更为热情的怀抱、也将有更多足以激励消费者进行购买的新型Java产品不断涌现。
事实上，甲骨文仅仅是对Sun产品组合中那些因为成熟度不高而无法出售的方案进行了修补。这项举措本身没有问题，但却让甲骨文在对应领域的一些孱弱产品处于更加风雨飘摇的状态。甲骨文随后又进一步继续着Sun未能完成的拉拢盟友工作，并向谷歌提起专利诉讼、从而给整个Java生态系统造成了附带危害。不用说，这也是甲骨文公司的一贯风格了，倒也不足为奇。
Java迎来哪些主要新功能?
在Java 7与Java 8当中，我们发现不少能够哄开发者开心的特性，但却没有任何新鲜或者转折性的亮点。因此Typesafe开始寄希望于Scala，开发人员在表达了对这些特性的喜爱好、甲骨文又开始将其加入Java。这使得来自大型企业而又希望能利用Scala编写软件的开发人员们享受到了自己最爱的便捷功能，但却需要忍受Java当中那略有些偏差的语法规则。
这种方式对于“商品化”与“标准化”而言非常重要，但却彻底扼杀了新思路与转折性成果的生存空间。所谓转折性成果，是指那些足以开拓出全新市场的方案。Java就是这样的一种转折性成果：“一次编写、全平台运行”，在具备垃圾回收机制的虚拟机中使用这种类型安全语言能够彻底帮助大家摆脱C++带来的噩梦。对于企业用户来说，这个理由也充分到足以促使他们将现有软件利用Java重新编写一遍。相比之下，Lambda项目在转折重量级方面根本无法与Java本身相提并论。
尽管如此，Java SE倒也算得上是套不错的解决方案。但甲骨文却一直在不遗余力地毁掉这款不错的作品。与此同时，作为最大竞争对手的微软又起到了落井下石的作用。不过在我看来，在微软意识到Azure、Office 365以及BizTalk作为平台的潜力并将开发重心转向云环境的同时，Windows已经成为早晚要被深埋永葬的活死人。
Java EE又是另一回事
Java EE已经长期陷入停滞。大家还记得它的最新版本是何时公布的吗?我也不记得，当然我也不在乎。还记得WebLogic吗?还记得当初Sun曾经称之为基于GlssFish的应用服务器吗?我也不记得了。与此同时，红帽正忙于利用OpenShift构建属于自己的发展前景，当然其中JBoss也会发挥一定的作用。EMC和他手下的两位小弟VMware以及Pivotal正积极讨论Cloud Foundry的可行性，但目前其销售重点仍然放在与Greenplum数据库紧密结合的Hadoop方案身上。
换句话来说，Java EE已经落后于整个行业的平均发展节奏。甲骨文向来不关心人们的内心感受，而这种糟糕的处事态度彻底毁掉了Java社区的构建进程，并最终导致Java EE始终无法健康成长。Java社区进程是一项政治性尝试，希望能让供应商们(特别是IBM)留在Java阵营吵杂中。最近几年以来，Java领域最卓越的衍生成果无疑是Android，然而甲骨文却因为这个而跟谷歌打起了侵权官司。其余创新活动全部发生在开源领域，而甲骨文的作法则是与Apache渐行渐远。在这种情况下，Java社区进程还能有什么作为?
关于Java EE生态系统我们还有更多可谈的，毫无疑问，这里指的是Spring。不过Rod Johnson已经跑去为Typeszfe工作，而VMware则将Spring推向了Pivotal那杂乱纷繁的技术培育环境(其中包括云计算、数据仓库、Hadoop以及Spring，很明显后者与前几项毫不相干)。这种状况确实不是甲骨文直接造成的，但现在我们要强调的是Java EE生态系统的发展机遇。总结而言，Java EE目前未能成为任何一家厂商的业务战略核心组成部分——除非他们希望拿这个当宣传噱头。
是什么在支撑着Java?
支撑着Java的是一种惯性。如果大家需要一种跨平台运行时环境，那么JVM无疑是最理想的现成选择。Java的从业者数量极大，而且具备相当可观的安装基础，从业务管理者的角度来看、只有白痴才会忽视这样一套主流方案。
正是由于这种惯性，Hadoop才会选择利用Java进行开发(大部分由Java开发而成)而非其它语言。在过去一年中，我曾经跟很多原本使用.Net环境但却突然转而部署其首套Linux平台与Java运行时的企业用户进行交流，他们表示这一切完全是为了支持Hadoop。
如何让Java恢复生机?
目前的不利局面部分属于成熟周期当中的必要阶段。正如微软在发展中学到的经验，我们无法在建立新的信徒与拥护者群体前抛出任何新方案。甲骨文推出了一个项目，旨在最终“修复”Java并解决几年前Sun一直没能妥善处理的List<int>遗留问题。这样的改善程度太有限也太晚了，而且无论从哪个角度来看，这都不能算是转折性成果。转折性成果从业务角度看应该能够“让客户接受__，使他们能够下决心进行__，从而让我们向其出售__”(三处的正确答案分别为创造性、颠覆和产品)，虽然听起来像是笑话、但实际情况正是如此。
近年来涌现的转折性技术成果有云计算、NoSQL以及大数据。这些技术能够开辟新的解决思路，并给旧有机制带来更为低廉的成本。我们显然不可能把Java EE(也可能是CE或者DE)拔高到这样的顶尖地位，当然也不可能指望甲骨文把这套无甚发展前景的机制摆上议事日程。
前景预测
我认为甲骨文不太懂得如何开拓市场。他们最擅长的是毁掉现有市场并以此为基础突出自己的产品方案，但在Java的这场战争中他们显然没能发挥优势。在我看来，Java还将存在很长很长一段时间，但真正留给它的发展时间不多了。要想扭转局势，Java必须证明自身在广受接纳的运行时环境与编程语言之外更为广泛的实际能力。至少我个人看不到甲骨文在推进Java领导地位方面所作出的任何努力，而且这也跟甲骨文公司一直以来的定位不符。
相反，甲骨文将与更多厂商对簿公堂，采取更多短期性与自卫性举措，而后在IBM与红帽等退出之前悄悄消失在运行时业务领域、留下这些企业收拾残局。这绝不是危言耸听，而确实已经显露出端倪。
