想要恢复Java生机:甲骨文需要做什么?

　　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目前未能成为任何一家厂商的业务战略核心组成部分——除非他们希望拿这个当宣传噱头。