いじるのはやめてください。これらの機能は Java 21 で非推奨となり削除される予定です。

Java は、私がこれまで使用した中で最も下位互換性のある言語および環境の 1 つですが、機能が非推奨になったり削除されたりする可能性は常にあります。 Java 21 では 2 つの機能が廃止されます。それが今日お話しする内容です。

1 なぜ機能を非推奨にしなければならないのでしょうか?

コードや機能の非推奨とは、その使用が推奨されず、将来のバージョンには存在しない可能性があることを意味します。それが推奨されない理由はたくさんあるでしょう。

非推奨の最も一般的な理由は次のとおりです:

• これは、より優れた代替手段によって置き換えられました。
• 設計上の欠陥があり、使用すると危険な場合もあります。ただし、下位互換性があるため、すぐに削除することはできず、まったく削除することもできません。
• これは冗長であると考えられるため、システムとその使用方法を簡素化するために削除する必要があります。
• 今後のアップデートにより、古い機能/コードのサポートが不可能/非現実的になります。

根本原因に関係なく、非推奨の機能はまだシステムの一部であるため、少なくとも現時点では引き続き使用できます。

Windows 32 ビット x86 ポートの非推奨

JEP449 は、Windows の 32 ビット x86 サポートを非推奨にし、将来的に完全に削除することを最終目標としています。

この非推奨と将来の削除の背後にある理由は、主に技術的なものです。

Windows 32 ビットのサポート

あらゆるシステムにソフトウェアを提供するには、実際にどのプラットフォームをサポートするかを常に決定する必要があります。サポートされなくなったプラットフォームやバージョンをターゲットにすることは可能ですが、通常はサポートの取り組みを強化したり、バックポートしたり、自分で修正したりすることを意味します。

Windows プラットフォームを例に挙げると、最後の 32 ビット バージョンは 2020 年にリリースされ、公式サポートは 2025 年 10 月に終了しました。

64 ビット Windows が 32 ビット アプリケーションをどのように処理するかを知っている場合は、なぜ Windows に統合された WOW64 エミュレーション層を介して JVM を実行できないのか不思議に思うかもしれません。通常、この方法でアプリケーションを実行することは可能ですが、パフォーマンスは大幅に低下します。

これが、Java の将来のバージョンにのみ影響するため、OpenJDK チームが非推奨を進めることを決定した理由です。古いシステムでは、削除される前のすべての Java バージョンを引き続き使用できます。

Java 21 での直接的な変更の 1 つは、ビルドを構成する機能がデフォルトで無効になっているため、JDK のビルド プロセスに影響します。 bash ./configure を実行しようとすると、エラーが発生します:

...checking compilation type... nativeconfigure: 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... nativeconfigure: 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 MBThe 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) の追加もその 1 つです。これにより、軽量 (仮想) スレッドが導入され、Java で高スループットの同時アプリケーションを処理する方法が大幅に変わる可能性があり、そのようなアプリケーションの作成、保守、監視に必要な労力が軽減されます。従来のプラットフォーム (カーネル) スレッドよりもオーバーヘッドがはるかに少なくなります。

ただし、Windows 32 ビット x86 では、技術的な制限により、この機能はカーネル スレッドにフォールバックする必要があります。基盤となるプラットフォームに欠けている機能は、多くの場合、将来の非推奨や削除の強力な指標となります。

それでも、新しいスレッド コードを作成して使用することはできますが、実際には期待される利点がありません。

非推奨ですが、まだ削除されていません

ご覧のとおり、Windows 32 ビット x86 はいずれにせよ動作しないため、非推奨になるのは理にかなっています。さらに、特定のプラットフォーム向けにビルドすることは引き続き可能ですが、現時点では推奨されていません。したがって、レガシー システムをサポートする必要があり、自分が何をしているのか、その結果がどのようなものかを理解している場合でも、引き続きそれを使用できます。

エージェントの動的読み込みを無効にする

エージェントはインストルメンテーション API を使用して、JVM にロードされているバイトコードを変更することで既存のアプリケーションを変更します。これにより、実際にソース コードを変更せずにアプリケーションの動作を変更できます。これは、プロファイラーや監視ツール (Datadog や YourKit など)、アスペクト指向プログラミングなどでよく使用されます。

エージェントのロード方法

エージェントをロードするには 2 つの方法があります。1 つはパラメータを追加するか呼び出して静的にロードする方法、もう 1 つは実行する方法です。次のコードは別のアプリケーションから動的にロードされます。 -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 workvm.detach();} catch (Exception e) {// ...}}}

最初のオプションは大きな問題ではありません。これは明らかに JVM エージェントの意図的な使用です。ただし、後者は間接的なものであり、接続された JVM によって制御されない場合があります。

动态加载的问题

Java 平台默认致力于实现完整性，为我们构建应用程序提供强大而坚实的基础。代理的设计考虑到了最好的意图，为您提供（良性）工具的力量。然而，为了确保这种完整性，通过（动态）代理进行检测是一个大问题，因为它们超出了您的直接控制范围，并且可能会对您的应用程序造成严重破坏。这就是为什么您作为应用程序的所有者必须对允许和加载哪些代理做出有意识且明确的决定。

插播一条，如果你近期准备面试跳槽，建议在ddkk.com在线刷题，涵盖 1万+ 道 Java 面试题，几乎覆盖了所有主流技术面试题，还有市面上最全的技术栈500套，精品系列教程，免费提供。

在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 warningWARNING: If a serviceability tool is not in use, please run with -Djdk.instrument.traceUsage for more informationWARNING: 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。随着时间的推移，它正在成为技术债务，最终必须偿还。没有什么比因为不相关的原因而需要升级代码更有压力的了，而且您多年来依赖的一些已弃用的功能最终被删除，使得升级方式比需要的更加复杂。

以上がいじるのはやめてください。これらの機能は Java 21 で非推奨となり削除される予定です。の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。