本文來源（https://foojay.io/today/upgrade-a-java-8-project-to-11-or-higher/）
Java 8 is a Long Term Supported (LTS) version, and Azul will maintain it until 2030 for customers with a support license. You can continue to run Java 8 applications until then on updated and secure Java runtimes. But by staying on Java 8, you miss many other improvements in runtime performance and language enhancements for your developers.
Java 8 是長期支持 （LTS） 版本，對於擁有支持許可證的客戶，Azul 將將其維護到 2030 年。在此之前，您可以在更新和安全的 Java 運行時上繼續運行 Java 8 應用程序。但是，如果繼續使用 Java 8，您將錯過開發人員在運行時性能和語言增強方面的許多其他改進。
Keeping a project on Java 8 will eventually lead to running it on a non-maintained runtime.
將項目保留在 Java 8 上最終將導致在非維護運行時上運行它。
In an earlier article, Unsupported Versions of Java Are Dangerous, Simon Ritter points out the problems if you are still running on an older version – Java 7 in this case – that is no longer supported.
在之前的一篇文章《不支持的Java版本是危險的》中，Simon Ritter指出了在這種情況下仍在舊版本的Java 7上運行的問題 - 不再支持。
Azul still supports Java 7 until 2027, but other distributions do not support it. You can find the complete support lifecycle for existing and planned JDK releases on the Azul website.
Azul 在 2027 年之前仍然支持 Java 7，但其他發行版不支持它。您可以在 Azul 網站上找到現有和計劃的 JDK 版本的完整支持生命週期。
"The adage 'if it ain’t broke, don’t fix it' is often applied to deployed applications. As a result, almost all production enterprise applications, including mission-critical ones, are still running on older versions of Java. Sometimes very old… and sometimes unsupported versions of Java." — Simon Ritter, Deputy CTO, Azul
“'如果它沒有壞，就不要修理它'這句格言經常適用於已部署的應用程序。因此，幾乎所有的生產企業應用程序（包括任務關鍵型應用程序）仍在舊版本的 Java 上運行。有時很老...有時還有不受支持的Java版本“——Simon Ritter，Azul副首席技術官
What are you Missing in Java 8?
你在Java 8中缺少什麼？
Since Java moved to a 6-month release cycle in 2018, each new version brings new features and performance improvements. In most enterprise environments, organizations decide to stick to the LTS versions (11 in 2018, 17 in 2021, 21 in September 2023), which is a reasonable option as it prevents going through significant test cycles every six months.
自從 Java 在 2018 年進入 6 個月的發佈週期以來，每個新版本都會帶來新功能和性能改進。在大多數企業環境中，組織決定堅持使用 LTS 版本（2018 年 11 個，2021 年 17 個，2023 年 9 月爲 21 個），這是一個合理的選擇，因爲它可以防止每六個月經歷一次重要的測試周期。
But by sticking to an older version, your DevOps and developer teams are missing a lot of tools that would allow them to make more performant and better-written applications. The article 9 Outdated Ideas About Java gives an overview of several Java evolutions between versions 8 and 19.
但是，通過堅持使用舊版本，您的 DevOps 和開發人員團隊缺少許多工具，這些工具可以讓他們製作性能更高、編寫更好的應用程序。文章 9 關於 Java 的過時想法概述了版本 8 和 19 之間的幾個 Java 演變。
Running applications on a newer JDK
在較新的 JDK 上運行應用程序
As Java always has aimed to keep stability in the runtimes, in most cases you can execute your Java 8 application without any modifications on a newer JDK.
由於 Java 始終致力於保持運行時的穩定性，因此在大多數情況下，您無需在較新的 JDK 上進行任何修改即可執行 Java 8 應用程序。
The significant disadvantage of this approach is that your development environment is stuck to this old version. 此方法的顯著缺點是您的開發環境堅持使用此舊版本。
Further maintenance will become more complex as IDEs and build tools move on and create more problems in the code. 隨着 IDE 和構建工具的發展並在代碼中產生更多問題，進一步的維護將變得更加複雜。
What are the challenges of migrating from 8 to a newer Java?
從 8 遷移到較新的 Java 有哪些挑戰？
The move from 8 to 11 has a more significant impact compared to 11 to 17. The main reason is multiple changes introduced in Java 9.
與11到17相比，從8到11的轉變具有更顯着的影響。主要原因是Java 9中引入了多個更改。
Specifically, the introduction of the module system and – more importantly – the encapsulation of the internal JDK APIs.
具體來說，模塊系統的引入，更重要的是內部JDK API的封裝。
- Modules JDK 9 introduced modularity at two levels:
JDK 9 在兩個級別引入了模塊化：
in the JDK – all the class libraries (around 4,500) are packaged into modules as described in JEP-200. This allows combining JDK modules at compile time, build time, and run time into various configurations. These include the full JDK, configurations equivalent to the previously known JRE (Java Runtime Environment), custom configurations tailored to specific applications, etc.
在JDK中，所有類庫（大約4，500個）都打包到JEP-200中所述的模塊中。這允許在編譯時、構建時和運行時將 JDK 模塊組合到各種配置中。其中包括完整的JDK，相當於以前已知的JRE（Java運行時環境）的配置，針對特定應用程序定製的自定義配置等。
in application code – as a developer, you can break your application into modules. This is not a requirement but it could simplify upgrade processes, although this is not widely used.
在作爲開發人員的應用程序代碼中，您可以將應用程序分解爲模塊。這不是必需的，但它可以簡化升級過程，儘管這並沒有被廣泛使用。
If you keep all jars in the classpath, your existing application should still work, and modularity won’t have an impact.
如果將所有 jar 保留在類路徑中，則現有應用程序應該仍然可以工作，並且模塊化不會產生影響。
- Internal APIs 2. 內部接口 With the move to Java 9 and the integration of modularity, some internal APIs got encapsulated and are no longer accessible. The most well-known one is sun.misc.Unsafe. The
Unsafename should ring a bell as this indicates that it was never intended or recommended to be used by Java developers.
隨着遷移到Java 9和模塊化的集成，一些內部API被封裝並且不再可訪問。最著名的是 sun.misc.Unsafe 。“不安全”這個名字應該敲響警鐘，因爲這表明它從未打算或推薦被Java開發人員使用。
On top, as the implementation of these internal APIs is not part of the Java Technology Compatibility Kit (TCK), their implementation is not identical in the various JDK distributions. Still – as sun.misc.Unsafe provides control of low-level systems like memory manipulation – it was used in projects that wanted to achieve specific performance improvements, for example Log4j and Spring.
最重要的是，由於這些內部API的實現不是Java技術兼容性工具包（TCK）的一部分，因此它們的實現在各種JDK發行版中並不相同。仍然因爲 sun.misc.Unsafe 提供了對低級系統的控制，如內存操作，它被用於想要實現特定性能改進的項目，例如 Log4j 和 Spring。
These projects had to be adapted to handle this encapsulation and the changes in the JDK, meaning you will probably need to upgrade to new versions of these dependencies, which may also introduce other changes that will impact your application code.
這些項目必須進行調整以處理此封裝和 JDK 中的更改，這意味着您可能需要升級到這些依賴項的新版本，這還可能引入會影響應用程序代碼的其他更改。
To be able to estimate the impact of these changes since Java 9, an extra tool was added in the JDK called jdeps that can analyze your code and tell you where these internal APIs are used. This is further described in the Java Dependency Analysis Tool.
爲了能夠估計自 Java 9 以來這些更改的影響，JDK 中添加了一個名爲 jdeps 的額外工具，它可以分析您的代碼並告訴您這些內部 API 的使用位置。Java 依賴關係分析工具中對此進行了進一步描述。
Why Migrate from Java 8 to 11
爲什麼要從 Java 8 遷移到 11
Why Migrate from Java 8 to 17
爲什麼要從 Java 8 遷移到 17
The move from 8 to 11 has a more significant impact than from 11 to 17
從 8 到 11 的轉變比從 11 到 17 的影響更大
If the migration fails, you can fall back to Java 11
如果遷移失敗，您可以回退到 Java 11
More libraries are likely to be compatible with Java 11
更多庫可能與Java 11兼容
The impact of changes between Java 11 and 17 is much lower than between Java 8 and 11
Java 11 和 17 之間更改的影響遠低於 Java 8 和 11 之間
The migration from Java 8 to 17 requires an estimated 20% more effort 從 Java 8 遷移到 17 需要多付出 20% 的努力
It will be easier to migrate to Java 21 from Java 17
從Java 17遷移到Java 21會更容易
Java 9 introduced modules and changes to internal APIs
Java 9引入了模塊和對內部API的更改
Estimating the impact of outdated third-party libraries is under your control
估計過時的第三方庫的影響在您的控制之下
Deciding to migrate to Java 11 or Java 17
決定遷移到 Java 11 或 Java 17
"When you are upgrading your codebase and dependencies to a newer Java version, you also need to take into consideration that libraries might already have moved to JDK11 or even JDK17, and with this, they no longer support older JDKs. This means they won’t provide security fixes either, which could be a security problem. In many cases, this would also be a reason to move to at least JDK11." — Gerrit Grunwald, Senior Developer Advocate, Azul
“當你將代碼庫和依賴項升級到更新的Java版本時，你還需要考慮到庫可能已經遷移到JDK11甚至JDK17，因此，它們不再支持較舊的JDK。這意味着他們也不會提供安全修復程序，這可能是一個安全問題。在許多情況下，這也是遷移到至少JDK11的原因。
Migrating from Java 8 to a Newer LTS Version
從 Java 8 遷移到較新的 LTS 版本
At the moment, it makes perfect sense to move directly from Java 8 to 17 (the latest LTS version), allowing you to move more quickly to the upcoming 21 LTS later this year.
目前，直接從Java 8遷移到17（最新的LTS版本）是完全有意義的，這樣您就可以更快地遷移到今年晚些時候即將推出的21 LTS。
The impact of changes between Java 11, 17, and 21 is much lower compared to the differences between Java 8 and 11.
與 Java 8 和 11 之間的差異相比，Java 11、17 和 21 之間更改的影響要小得多。
One of the main challenges for such a migration will probably be the third-party libraries used in your project. The more of these libraries you use, the more likely one of them does not support Java 17 yet.
此類遷移的主要挑戰之一可能是項目中使用的第三方庫。您使用的這些庫越多，其中一個庫還不支持 Java 17 的可能性就越大。
It’s recommended to start with the creation of a list of dependencies, and research them to find out what the current state of these is.
建議從創建依賴項列表開始，並研究它們以找出這些依賴項的當前狀態。
The possible outcomes are:
可能的結果是：
Outcome 結果 Significance 意義
The library is no longer maintained and is not compatible with Java 11 and/or 17
該庫不再維護，並且與 Java 11 和/或 17 不兼容
A replacement is needed, which can result in significant changes in your project
需要更換，這可能會導致項目發生重大變化
The library has evolved and is available in a newer version which is compatible with Java 11 and/or 17
該庫已經發展，並提供了與Java 11和/或17兼容的較新版本
Minor impact, update the version and check if you need to refactor
影響較小，請更新版本並檢查是否需要重構
The library is not yet supported on Java 11 and/or 17
Java 11 和/或 17 尚不支持該庫
Wait or replace it, maybe contributing back to the library project to speed up development for support
等待或替換它，也許回饋庫項目以加快開發以獲得支持
Outcomes and significance of dependency research
依賴性研究的結果和意義
Anyhow, the biggest challenge of migrating a project is... time! If the code itself and the libraries are compatible with Java 11 and/or 17, only minor changes will be needed, and the migration will mainly be a task for the QA team. But if incompatibilities are found, the timeline can become unpredictable.
無論如何，遷移項目的最大挑戰是...時間！如果代碼本身和庫與 Java 11 和/或 17 兼容，則只需要進行微小的更改，遷移將主要是 QA 團隊的任務。但是，如果發現不兼容，時間線可能會變得不可預測。
Regarding the actual migration, there are no specific patterns to follow. Updating the Java version, e.g., in the pom-file of a Maven project, will probably already show the most important code parts to be reviewed as they will break the build.
關於實際遷移，沒有具體的模式可以遵循。更新Java版本，例如，在Maven項目的pom文件中，可能已經顯示了要審查的最重要的代碼部分，因爲它們會破壞構建。
From there it’s an organizational problem, as the need must be well-defined to push the migration forward and make it happen. Further delays will bite you back hard later… Making it happen fast will also prevent extended simultaneous maintenance of the original project and the migrated project, which can prove difficult.
從那裏開始，這是一個組織問題，因爲必須明確定義需求以推動遷移並實現遷移。進一步的延誤會在以後狠狠地咬你一口......快速實現它還將防止對原始項目和遷移的項目進行長時間的同時維護，這可能會很困難。
"From my experience, while assisting customers during their upgrade, I’ve seen that it’s worth trying to move immediately from Java 8 to 17. If it fails, it will be because some library is not yet supporting 17. At that time, falling back to Java 11 is always possible, as all cleanup done for the Java 17 move will be usable for the Java 11 move. But I would strongly recommend not using Java 17 coding features during the move. Limit those to what Java 11 provides. As soon as you complete the move to either Java 11 or 17 and the application is running as expected, the second round of migration can be started to simplify the code based on the new possibilities that were introduced in the more recent versions of Java. From a risk management and effort perspective, I think the migration from Java 8 to 17 needs an estimated 20% more effort than from Java 8 to 11. The biggest problems in a migration project I have seen at a customer were caused by an ad hoc and last-minute project where the impact of outdated third-party libraries was not correctly estimated." — Michael Roeschter, Sales Engineer, Azul
“根據我的經驗，在幫助客戶升級時，我已經看到立即嘗試從Java 8遷移到Java 17是值得的。如果失敗，那是因爲某些庫尚不支持 17。此時，回退到 Java 11 總是可能的，因爲爲 Java 17 移動所做的所有清理都將可用於 Java 11 移動。但我強烈建議在移動過程中不要使用 Java 17 編碼功能。將這些限制爲 Java 11 提供的內容。一旦您完成了向 Java 11 或 17 的遷移，並且應用程序按預期運行，就可以開始第二輪遷移，以基於較新版本的 Java 中引入的新可能性來簡化代碼。從風險管理和工作量的角度來看，我認爲從 Java 8 遷移到 17 需要的工作量估計比從 Java 8 遷移到 Java 11 多 20%。我在客戶那裏看到的遷移項目中最大的問題是由一個臨時和最後一刻的項目引起的，在這個項目中，過時的第三方庫的影響沒有得到正確的估計。
Conclusion 結論
Yes, upgrading your application code from Java 8 to a newer version will take time and effort.
是的，將應用程序代碼從 Java 8 升級到較新版本需要花費時間和精力。
But postponing this process will only make it more complex.
但推遲這個過程只會使它變得更加複雜。
And in most cases it will become inevitable anyway.
在大多數情況下，無論如何它都會變得不可避免。
We recommend you cut to the chase and dive into the code to start the migration.
我們建議您切入正題並深入研究代碼以開始遷移。
Aim for the stars and go for Java 17! 瞄準星星，去爪哇17！
機器翻譯 湊合看。