若是Java 失宠于Oracle，那么将来会怎么样？

【编者按】对于前不久 Oracle 裁掉了一部分 Java 布道师，近日一位 Oracle 前高管称其为该机构对Java的「计划报废」。若是这个计划是属实的，那么对于寻常的开发者、已经采用了 Java 的公司、预备选择 Java 做为基础的创业者，究竟又会产生什么样的影响？近日，Jason Whaley 在 Dzone 上进行了详细的分析。本文由 OneAPM 工程师编译整理。

几个月前，Oracle 裁减了部分 Java 布道师。不久以后，一位 Oracle 前高管在发送给Infoworld 的邮件中称此举为「计划中的报废（planned obsolescence）」。

一位负责 Java 的 Oracle 前高管在周二发给 InfoWorld 的这封邮件中声称了解 Oracle 公司内部信息。邮件称 Oracle 正在转型为云公司，以期与 Salesforce 竞争。并且，「Java 已经彻底失宠」，主题栏的原文为「Java——计划中的报废」。

邮件还说，Oracle 不想给竞争对手更多资源，不想分享创新成果。Oracle 正在缩减对 Java EE (企业版)的投入，同时它也不但愿别的公司接手 Java 或 Java EE，并且它正逐步将 JCP (Java Community Process) 打入冷宫。邮件称：“它们抱着赢者通吃的想法，再也不热衷于合做”。「WebLogic 的专利申请将会逐步完成，同时，也会推出一个专利的微服务平台。」WebLogic 是 Oracle 在2008年收购 BEA Systems 时获得的 Java 应用服务器。

若是以上陈述有一半属实，那 Oracle 的想法和计划真是至关吓人。如今，将上面的陈述与下面的事实一块儿考虑。事实上，Oracle 掌握了 Java 大部分的全部权。

• Java 语言、Java 虚拟机以及标准的 API 都是遵循 GPL 许可的开源资源。
• 在收购了 Sun Microsystems 以后，Oracle 成为该知识产权的全部者。
• Oracle 敢于经过代价高昂的法律诉讼维护其知识产权——它与 Google 围绕 Android 的官司就是证实。
• 那次官司的结果是法律不支持 Java API 被复制或分支（copy/fork），也不支持经过封装或重命名的方式移为他用。
• Java Community Process 是目前惟一能够改变该语言核心或标准 API 的方式。
• 第三方供应商若想开发 Java 工具并大量发售，必须得到（大可能是以购买）Oracle 的许可。

最后，将以上全部事实与 Oracle—— Java 惟一拥有者的将来计划一块儿考虑。

• 不打算对 Java 进行有意义的更新
• 不以为有必要布道其产品以提升采用量或鼓励创新应用
• 只由于 Java 是其余专利产品的开发基础才以为它有用

是否是以为有点夸大其实？多是吧。但若是 Oracle 真打算将 Java 平台投入维护模式，以上想法并不是无稽之谈。那么，对于天天依赖 Java 或 JVM 工做的寻常开发者而言，这冷酷的前景意味着什么呢？对于那些以 Java 技术为软件基础架构支撑的公司而言，又意味着什么呢？对那些正准备用 Java 编写产品原型或 MVP(最小化可行产品)的初创者，又如何呢？前面全部问题的答案是：“没有任何影响。至少如今是这样。”

对于寻常的开发者

Java 仍旧是当下部署最普遍、使用最广泛的平台语言。我掌握的一手资料显示，今年的 JavaOne 大会依旧充满生机。现今主流的基础架构仍是以 Java 为基础构建。在 TIOBE（编程语言排行榜）上，Java 仍是跟 C 一块儿，交替处于榜首。

围绕 Oracle 裁减布道师的阴云与猜想并不会对雇主们的 Java 或 JVM 技能需求产生任何影响，今天不会，明天不会，明年也不会——恐怕要有好一阵才有影响。即使 Java 语言和标准 API 的普及率降低了，愈来愈多的新语言正以更快的速度基于 Java 平台进行开发，那些（更广泛的状况）自带 API 的语言，每每也是基于标准 API 的。

以上全部开发都依赖于该家喻户晓的热点 JVM，那 Oracle 对其知识产权的控制又如何呢？即使 Java 再也不流行，仍有 Azul 之类的公司愿意向 Oracle 购买证书从而经过其兼容的 JVM 赚钱，好比他们的商业产品 Zing 以及免费的 Zulu。

对于寻常的开发者，这个新闻无须挂怀。即使是那些将所有职业生涯都赌在 Java 这一种平台的开发者，这么作虽然比较不明智，但也不用担忧。围绕 Java 生态系统的技能与知识需求不会在短期内消失。

对已经采用了 Java 的公司

与平常开发者差很少，变化也不大。以前就在基础机构中采用了 Java 的公司早就赌定 Java 能帮助其完成既定的商业目标——即便该平台的背后支持是传说中「邪恶」的 Oracle，或更早以前，一直都穷困潦倒的 Sun Microsystems。 这些全面展开的系统既然能实现商业目标，就不能由于它们创建在 Oracle 发布的平台之上，而沦为抛弃对象。

通常而言，在短期内重写或替代重要基础架构中的 Java 组件的成本与风险远远大于回报。此处的回报是在将来，你新采用的平台变得很是广泛从而最终下降成本、提升业务敏捷性。重写并替换工做系统是很是危险的冒险——只要看看 Netscape 的例子就知道了。即使一个公司顺利地完成了迁移，回报也只能在多年之后得以实现。

若无论替换工做系统的问题，为了不将来陷入遗留系统的困境，已经采用 Java 的公司组织能够将基础架构迁移至微服务模型（microservices model）以下降风险。微服务策略也是一把双刃剑，该话题在软件开发领域还处于热烈的讨论阶段，包括什么时候、何处、如何部署微服务架构。但如果担忧与 Oracle 中止开发的平台绑定的潜在风险，机警的公司至少能够经过微服务，逐步地，替换或孤立以 Java 为基础的服务组件。

新的项目该何去何从呢？

若是你正在筹备新的科技公司或启动内部新项目，而且以为 Java 是合适的技术选择，就须要讨论一下该不应以 Java 生态系统为基础。讨论的焦点仍是集中在可能产生的技术债务（technical debt）。在选择平台时这类技术债务彻底没法避免——区别在于这些债务的回报如何。

选择 Java 平台意味着得到健康广阔的生态系统，以及丰富的知识、劳动力与相关产品。做为交换，由此带来的技术债务在于，该平台也许没法适应将来的技术演进，由于其全部者不打算继续开发它。如今，你或许能够开发出健康的产品，尽管将来会的开发成本会愈来愈高，甚至牺牲将来的业务敏捷度。

其余的平台选择都有各自的技术债务。但简而言之，各有各的不一样。好比：

• 选择 Node.js 平台意味着缺乏丰富的稳定生态系统。但该平台很是活跃，欣欣向荣，可能会持续发展很长时间，并且 Node.js 人才也愈来愈多。
• 选择 Ruby（极可能与 Rails 一块儿）平台意味着能以合算的成本快速创建起工做系统的基础架构，但坏处是扩展性不佳。
• 你也能够选择 Microsoft/.NET 生态系统，该系统拥有一些与 Java 平台类似的优势，但缺点是你的公司命运会与另外一个企业软件巨头的选择绑定。

……还有许多其余选择，每一个选择都是利弊权衡的问题。

简而言之，是否选用 Java 平台做为新项目的基础平台很大程度上是我的决策。Oracle 可能厌倦了 Java，但这是否应该影响这个决策呢？固然应该。可是，这不应是惟一的考虑因素。尤为是借助 Java 生态系统创建项目，能可观地提升项目成功的机会。

原文连接：Even if Oracle is Losing Interest in Java, Should You Worry?

OneAPM for Java 可以深刻到全部 Java 应用内部完成应用性能管理和监控，包括代码级别性能问题的可见性、性能瓶颈的快速识别与追溯、真实用户体验监控、服务器监控和端到端的应用性能管理。想阅读更多技术文章，请访问 OneAPM 官方博客。