幾個月前，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 生態系統建立項目，能可觀地提高項目成功的機會。

本文轉載自：

原文鏈接：