如果 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 生態系統建立專案，能可觀地提高專案成功的機會。