Netflix是如何從java8遷移到Java11? - carl

banq發表於2021-07-13
Java

Netflix 從 Java 8 遷移到 11 的案例研究心得： “我的方法和他們的方法之間的唯一區別是沒有絕望。”
在過去的兩年裡，我做了一件沒有人認為不可能的事情。我將我們的程式碼從 JDK 8 更新到 JDK 16。在我在 Netflix 完成的所有事情中，這是我問得最多的一件事，也是最令人驚訝的一件事。“你是怎麼做到的？”
當我加入 Netflix 時，沒有人告訴我從 Java 8 升級到 11 是不可能的。我剛剛開始使用它。當事情在 11 版本不起作用時，我去檢查是否需要更新庫。我在我自己的機器上將它作為一個次要專案進行，與主儲存庫分開。將所有非工作庫一一更新為工作庫。當一個庫與 Java 11 不相容時，我在 GitHub 上提交了一個 PR 來修復它。而且，聽起來很簡單，當沒有更多破碎的東西時，只剩下工作的東西！
直到我將這些更改推送到生產環境後，我才發現我所做的事情是不可能的。很多人問我是如何做到這一點的。某個人或某個團體看到了更新數百個專案和可能還有數百個庫的艱鉅任務，並已經放棄了希望。我的方法和他們的方法之間的唯一區別是沒有絕望。
如果您不熟悉 Java，Oracle 做出了一個艱難的決定來實現 Java 現代化。在 Java 9 之前，每隔幾年就會釋出一個主要版本，並且有相對較小的重大更改。所有這些在 Java 9 中都發生了變化；主要版本將被打破，每 6 個月釋出一次。
但是，與 Python 3000 不同的是，Java 的重大更改極其有限。只有 JVM 內部會被限制或刪除。就是這樣。所有現有的語言功能仍然可以使用。所有 JVM 位元組碼和類仍然有效。想使用 1995 年編寫的類嗎？如果它不依賴於sun.*程式碼，那很好！但是，這也是很多人認為升級不可能的原因。大量的 Java 程式碼隨意使用了 JDK 內部結構。
由於沒有 API 邊界，Java 8 幾乎可以讓應用程式和庫所有者做他們想做的事。Guice、Guava、Jackson、Groovy、Gradle、CGLib、Mockito、Lombok、ErrorProne 和其他常見的 Java 技術與 JVM 的膽量一起玩得不亦樂乎。是的，他們的程式碼更快。但不，這不是一場長期的勝利。
這就是從事 Java 工作的人做出的艱難決定發揮作用的地方。Java 可以改進自身、新增功能和改進 VM，但代價是破壞生態系統。
有兩點讓我印象深刻：
  1. 擁有強大的、可執行的 API 邊界對於長期改進是必要的。短期勝利雖然誘人，但通常伴隨著非標準或不受支援的行李。今天越嚴格，未來就越容易維護。
  2. 取消一些功能，即使在標準或規範的支援下，也會變得有害。如果它曾經有效，而你破壞了它，那是你的錯。



 

相關文章