彩票走势图

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

本文转载自：

原文链接：