Java 21 終於對這些功能動刀了！！

Java技术栈發表於2024-03-04
Java

來源：https://medium.com/@benweidig

儘管 Java 是我使用過的向後相容程度最高的語言和環境之一，但始終存在功能棄用甚至刪除的可能性。Java 21 將棄用兩個功能，這就是我們今天要討論的內容。

推薦一個開源免費的 Spring Boot 實戰專案：

https://github.com/javastacks/spring-boot-best-practice

1、為什麼要棄用功能？

棄用程式碼或功能意味著不鼓勵使用它，並且可能在未來的版本中不再存在。為什麼不鼓勵它可能有很多原因。

棄用的最常見原因是：

  • 它已被更好的替代方案所取代。
  • 存在設計缺陷，甚至使用起來可能存在危險。但由於向後相容性，它不能立即刪除，或者根本不能刪除。
  • 它被認為是多餘的，應該刪除以簡化系統及其使用方式。
  • 未來的更新將使得支援舊功能/程式碼變得不可能/不切實際。

無論根本原因如何，已棄用的功能仍然是系統的一部分，因此仍然可用，最起碼到現在。

棄用 Windows 32 位 x86 埠

JEP 449旨在棄用 Windows 的 32 位 x86 支援，最終目標是在將來完全刪除它。

這種棄用及其未來刪除背後的原因主要是技術性的。

Windows 32 位支援

為任何系統提供軟體總是需要決定您實際想要支援哪些平臺。針對不再受支援的平臺或版本是可能的，但通常意味著增加支援工作、向後移植、自行修復內容等。

以Windows平臺為例，最後一個32位版本於2020年釋出，官方支援於2025年10月結束。

如果您知道 64 位 Windows 如何處理 32 位應用程式，您可能想知道為什麼不能透過 Windows整合的 WOW64 模擬層來執行 JVM ？嗯，通常可以以這種方式執行應用程式，但效能會急劇下降。

這就是 OpenJDK 團隊決定繼續棄用的原因，因為它隻影響 Java 的未來版本。舊系統仍然可以使用刪除之前的所有 Java 版本。

Java 21 中的一項直接更改會影響 JDK 的構建過程，因為預設情況下禁用配置構建的可能性。嘗試執行bash ./configure會出現錯誤：

...
checking compilation type... native
configure: error: The Windows 32-bit x86 port is deprecated and may be removed in a future release. \
Use --enable-deprecated-ports=yes to suppress this error.
configure exiting with result code 1

由於該功能只是被棄用，而不是被刪除，因此 OpenJDK 團隊新增了新的配置選項（如錯誤所示），--enable-deprecated-ports=yes以仍然允許配置。但是，會發出警告以強調棄用和未來可能的刪除。

$ bash ./configure --enable-deprecated-ports=yes
...
checking compilation type... native
configure: WARNING: The Windows 32-bit x86 port is deprecated and may be removed in a future release.
...
Build performance summary:
* Cores to use:   32
* Memory limit:   96601 MB

The following warnings were produced. Repeated here for convenience:
WARNING: The Windows 32-bit x86 port is deprecated and may be removed in a future release.
虛擬 VS 核心執行緒

Java 21 充滿了令人敬畏的新功能，虛擬執行緒 (JEP 444)的新增就是其中之一。它引入了輕量級（虛擬）執行緒，這可能會透過減少編寫、維護和觀察此類應用程式所需的工作量，從而顯著改變我們處理 Java 中高吞吐量併發應用程式的方式。它們的開銷比傳統平臺（核心）執行緒少得多。

然而，在 Windows 32 位 x86 上，由於技術限制，此功能必須回退到核心執行緒。底層平臺的這種缺失功能通常是未來棄用和刪除的有力指標。

儘管如此，您仍然可以編寫和使用新的執行緒程式碼，但在實際操作中卻缺少預期的好處。

已棄用，但尚未刪除

正如您所看到的，棄用是有道理的，因為 Windows 32 位 x86 無論如何都無法執行。此外，針對特定平臺進行構建仍然是可能的，只是目前不鼓勵這樣做。因此，如果您仍然需要支援遺留系統並知道您在做什麼以及後果是什麼，您仍然可以使用它。

禁止動態載入代理

代理使用Instrumentation API透過更改 JVM 中已載入的位元組碼來修改現有應用程式。這使您能夠更改應用程式的行為，而無需實際更改其原始碼。它通常用於分析器和監視工具（例如Datadog和YourKit）、面向方面的程式設計等等。

如何載入代理

有兩種方法可以載入代理，一種是透過新增引數或呼叫來靜態載入，另一種是透過執行如下程式碼從另一個應用程式動態載入：-javaagent:agent-to-load.jar-agentlib:optionsjava

import java.lang.management.ManagementFactory;
import com.sun.tools.attach.VirtualMachine;

public class DynamicAgentLoader {

  public static void main(String... args) {

    int pidOfOtherJVM = ...;
    File agentJar = ...;

    try {
      VirtualMachine vm = VirtualMachine.attach(pidOfOtherJVM);
      vm.loadAgent(agentJar.toAbsolutePath);

      // ... do your work

      vm.detach();
    } catch (Exception e) {
      // ...
    }
  }
}

第一個選項問題不大。這是對 JVM 代理的明確且有意的使用。然而，後者是間接的，並且可能不受所連線的 JVM 的控制。

動態載入的問題

Java 平臺預設致力於實現完整性，為我們構建應用程式提供強大而堅實的基礎。代理的設計考慮到了最好的意圖，為您提供（良性）工具的力量。然而，為了確保這種完整性，透過（動態）代理進行檢測是一個大問題，因為它們超出了您的直接控制範圍，並且可能會對您的應用程式造成嚴重破壞。這就是為什麼您作為應用程式的所有者必須對允許和載入哪些代理做出有意識且明確的決定。

在 Java 21 中，您仍然可以載入動態代理，但 JVM 會生成多個警告，通知您潛在的問題以及如何隱藏這些警告：

WARNING: A {Java,JVM TI} agent has been loaded dynamically (file:/path/to/agent.jar)
WARNING: If a serviceability tool is in use, please run with -XX:+EnableDynamicAgentLoading to hide this warning
WARNING: If a serviceability tool is not in use, please run with -Djdk.instrument.traceUsage for more information
WARNING: Dynamic loading of agents will be disallowed by default in a future release

未來的 Java 版本將預設禁止載入動態代理，並且任何使用Attach API都會引發異常：

com.sun.tools.attach.AgentLoadException: Failed to load agent library: \
Dynamic agent loading is not enabled. Use -XX:+EnableDynamicAgentLoading \
to launch target VM.

異常訊息包括啟用動態代理載入所需的步驟：引數-XX:+EnableDynamicAgentLoading。因此，如果您有意識地決定允許動態代理，那麼您仍然可以。

立即禁用動態載入

到目前為止，僅發出警告。但是，您可以完全禁止動態載入 Java 代理。您可以透過使用將（加號）與（破折號/減號）-XX:-EnableDynamicAgentLoading交換的引數來執行此操作，以強化您的應用程式或為即將到來的更改做好準備。+-

2、結論

本文中提到的兩個功能的棄用對我來說是有道理的。

Windows 10 32 位 x86 支援是一項技術債務，阻礙了創新，例如利用虛擬執行緒的全部功能。

動態載入代理嚴重損害了 Java 平臺的完整性，並且存在潛在的安全風險。如果攻擊者“足夠接近”可以連線到另一個 JVM，那麼您可能會遇到更大的問題。

儘管如此，我們始終必須意識到將來可能會發生變化或刪除的內容，因為我們很可能無法決定它何時發生。Java 通常對棄用和刪除時間框架相當慷慨，某些功能可能會棄用數十年，但看不到刪除的跡象。所以很自然地，我們是否應該使用已棄用的 API 的問題就出現了。

在我看來，如果可能的話，我們應該儘量避免使用已棄用的 API。隨著時間的推移，它正在成為技術債務，最終必須償還。沒有什麼比因為不相關的原因而需要升級程式碼更有壓力的了，而且您多年來依賴的一些已棄用的功能最終被刪除，使得升級方式比需要的更加複雜。

更多文章推薦：

1.Spring Boot 3.x 教程，太全了！

2.2,000+ 道 Java面試題及答案整理(2024最新版)

3.免費獲取 IDEA 啟用碼的 7 種方式（2024最新版）

覺得不錯，別忘了隨手點贊+轉發哦！

相關文章