天天看點

Java17已經出現一年了,為什麼仍然有那麼多的公司使用Java8?

作者:萊迪娜的風聲

Java17 自2021年9月14日釋出以來已經一年的時間了,使用JDK8的小夥伴仍然有很多,是什麼原因導緻那麼多的使用者不願意更新Java版本?

Java17已經出現一年了,為什麼仍然有那麼多的公司使用Java8?
Java17已經出現一年了,為什麼仍然有那麼多的公司使用Java8?

一、你所使用的JDk開發版本是由你需要支援的最老的系統決定的,而不是最新的系統。有時,它可能會令人驚訝地古老。

二、平台更新總是有風險的。很早以前我将一個系統從Java 5更新到了Java 6,它破壞了JBoss。事實證明,那個版本的JBoss依賴于核心API傳回的數組中值的順序。API沒有承諾任何特定的順序,但JBoss實作假設順序總是相同的。它在Java 6中發生了變化,并迫使人們對自己的配置檔案進行一些更改,以便啟動JBoss。這令人驚訝,因為從5到6的過渡本該是無縫的。

三、從Java 8到Java17的過渡并不是無縫的,因為在9-10-11版本中有很多變化。這就是為什麼許多項目都堅持使用Java 8的主要原因。Java承諾“一次編寫,到處運作”,但它并沒有完全實作“永遠運作”。

以下是主要的轉變:

(1).Java 1.4到Java 5:在Java 5中,類字面量成為了jvm級别的實體。在Java 1.4中,當你引用一個類文字時,它會執行一個class位元組碼中的forName。從Java 5開始,對類字面量的引用将從常量池加載一個對象。這就産生了一個新的情況:一個類被加載但沒有初始化。一些現有的Java代碼假設,當你引用類字面量時,将調用它的靜态初始化式。這不再是正确的,并破壞了做這個假設的代碼。

(2).Java 6到Java 8: Java 7 JVM引入了方法句柄作為新的JVM實體。Java編譯器直到Java 8才使用它們,并在lambda表達式的實作中使用它們。是以Java 6到Java 7沒有做太多的工作,但是Java 8生成的位元組碼有一些主要的差別。除了像JBoss這樣令人驚訝的例子之外,這是對Java 5-7的無縫更新。

(3).Java 8到Java 9-10-11: Java 9引入了子產品系統。這是一個根本性的改變,它在執行反射時引入了關于可見性的新規則。它還從核心中完全删除了一些庫。Java開始遵循一種新的模式,即一個版本将更改表示為警告,下一個版本将使用禁用選項強制執行這些更改,而第三個版本将毫無例外地強制執行這些更改。從Java 8更新系統可能需要做很多工作,包括重新添加現在丢失的核心庫,以及在反射中處理新的可見性規則。

(4) . 比Java 11更好:雖然子產品系統帶來的巨大破壞在一段時間内不太可能再次發生(如果有的話),但我們将看到一系列穩定的棄用和删除,Java平台将糾正一些“過去的錯誤”。

四、在非常嚴肅的軟體開發世界中,隻有兩個月曆史的東西被普遍認為是“未經驗證的技術”、“重大安全問題”和“不合理的風險”。

五、關于“長期支援”、可能要到2022年底才會被考慮。就我而言,選擇繼續使用Java 8有點過于保守,但是,我了解這個決定。目前,可靠性和創新的最佳點(盡管對于Java開發來說這是一個強烈的詞)是Java 11。

六、在過去的三年中,它已經證明了自己,它是對Java 8的一個相當不錯的改進,值得一試。Java從11年到17年的發展方向是一個有趣的方向,盡管,讓我們誠實地說,它似乎是Kotlin 1.0中已經存在的東西的衍生品。認為這些特性有價值的項目已經在使用Kotlin而不是Java。

七、總而言之,Java 17 LTS肯定會被考慮,隻是不是現在。就像我在第一段說的,在我們考慮這個問題之前,可能要到2022年底或2023年初。

八、沒有商業理由更新。好的,再詳細一點:如果Java 17為他們提供了一個新特性,可以為他們節省幾千元或幾萬元,并且節省的金錢足夠多,讓他們有理由去冒更新的風險——這通常随着代碼庫的大小而增加——那麼他們就會更新。

九、為什麼要“更新”到一個沒什麼可提供的版本?也就是說,最好的做法是及時更新安全更新檔和小的改進。

十、靠炒作驅動的開發在實際的軟體開發世界中是行不通的。我們需要考慮在進行更新之前是否需要更新,這可能涉及到強調優點和強調缺點的人之間進行讨論。通常相容性不應該以任何方式犧牲,所有工作的都應該繼續工作。

十一、對于任何Java項目,你能保證更新始終是正确的嗎?接下來,如果以上都能保證,又能帶來什麼呢?更好的性能嗎?更經濟的記憶體使用?如果有新的功能,會是有益的嗎?如果是,以什麼方式?你必須回答所有的問題,而且要令人信服。我唯一一次成功說服版本更新是當我們的代碼需要剖析功能,而我們目前使用的版本不支援,我甚至嘗試過由于缺少低層子產品而去移植。

十二、沒有任何一個理智的項目經理會在建立的項目中使用最前沿的技術:風險和潛在的技術債務(程式碼當中一些不尋常的地方。)是很大的。任何一個理智的公司都不會重構現有的代碼庫來利用最新最好的特性。技術債務是相當大的,而其影響是未知的。目前,我仍然在維護一個使用Struts 1.0的Java 1.6應用程式。這是我日常工作的一部分(1-2小時)。你不能簡單地想着跳轉到另一個(最新的,嗖的一下)版本,然後就期待一切都順理成情理。保守地開發軟體,不加理會語言的新特性是正确方法。

十三、開發一個應用程式可能需要2到3年的時間,在這段時間内,很難不斷更新到最新版本的Java,同時仍然在實作系統方面取得進展,因為你最終将花費所有的時間重構代碼,以修複上次Java更新破壞的内容。是以,大多數公司在項目開始時選擇Java版本,并一直使用該版本,直到主要開發完成。然後他們将更新到較新的java版本視為技術債務(Technical Debt)。

十四、更新到新版本的Java通常需要更新到新版本的庫,這可能會影響到大量的傳遞依賴性。這就需要重構代碼,因為在庫的新版本中所做的更改是破壞性的。即使是那些試圖保持廣泛相容的庫,也經常會有與舊版本不相容的更改。是以必須測試所有内容(希望你有一個好的測試套件)。當所有的重構都完成并再次工作時,所有的東西又都過時了,是以這個循環永遠不會結束。