对于前不久 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?生态系统建立项目，能可观地提高项目成功的机会。