靠谱朗驰娱乐体育

几个月前，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 生态系统建立项目，能可观地提高项目成功的机会。

本文转载自：

原文链接：