Stop messing around, these features will be deprecated and removed in Java 21!

Although Java is one of the most backwards compatible languages ​​and environments I have ever used, there is always the possibility of functionality being deprecated or even removed. Java 21 will deprecate two features, and that’s what we’re going to talk about today.

1 Why should functionality be deprecated?

Deprecating code or functionality means that its use is discouraged and may no longer exist in a future version. There may be many reasons why it is not encouraged.

The most common reasons for deprecation are:

• It has been superseded by a better alternative.
• It has design flaws and may even be dangerous to use. But due to backward compatibility, it cannot be removed immediately, or at all.
• It is considered redundant and should be removed to simplify the system and how it is used.
• Future updates will make it impossible/impractical to support old functionality/code.

Regardless of the root cause, the deprecated functionality is still part of the system and therefore is still available, at least for now.

Deprecating Windows 32-bit x86 port

JEP449 aims to deprecate 32-bit x86 support for Windows, with the ultimate goal of removing it entirely in the future.

The reasons behind this deprecation and its future removal are primarily technical.

Windows 32-bit Support

Providing software for any system always requires deciding which platforms you actually want to support. Targeting platforms or versions that are no longer supported is possible, but usually means increasing support efforts, backporting, fixing things yourself, etc.

Taking the Windows platform as an example, the last 32-bit version was released in 2020, and official support ended in October 2025.

If you know how 64-bit Windows handles 32-bit applications, you may be wondering why you can't run the JVM through Windows' integrated WOW64 emulation layer? Well, it's usually possible to run applications this way, but performance will drop dramatically.

This is why the OpenJDK team decided to move forward with the deprecation, as it only affects future versions of Java. Older systems will still be able to use all Java versions prior to removal.

One of the direct changes in Java 21 affects the build process of the JDK, as the possibility to configure the build is disabled by default. Trying to run bash ./configure gives the error:

...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

Since the feature was simply deprecated, not removed, the OpenJDK team added a new configuration option (as shown in the error ), --enable-deprecated-ports=yes to still allow configuration. However, a warning will be issued to highlight deprecation and possible future removal.

$ 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.

Virtual VS Kernel Threads

Java 21 is full of awesome new features, and the addition of virtual threads (JEP 444) is one of them. It introduces lightweight (virtual) threads, which may significantly change the way we handle high-throughput concurrent applications in Java by reducing the effort required to write, maintain, and observe such applications. They have much less overhead than traditional platform (kernel) threads

However, on Windows 32-bit x86, due to technical limitations, this functionality must fall back to kernel threads. This missing functionality of the underlying platform is often a strong indicator of future deprecation and removal.

Still, you can write and use new threading code, but in practice it lacks the expected benefits.

Deprecated, but not yet removed

As you can see, the deprecation makes sense, since Windows 32-bit x86 won't run anyway. Additionally, building for specific platforms is still possible, it's just discouraged at this time. So if you still need to support legacy systems and know what you're doing and what the consequences are, you can still use it.

Disable dynamic loading of agents

The agent uses the Instrumentation API to modify existing applications by changing the bytecode that has been loaded in the JVM. This enables you to change the behavior of your application without actually changing its source code. It is commonly used in profilers and monitoring tools (such as Datadog and YourKit), aspect-oriented programming, and more.

How to load the agent

There are two ways to load the agent, one is to load it statically by adding parameters or calling, and the other is to run the following code from Another application is dynamically loaded: -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) {// ...}}}

The first option is not a big problem. This is a clear and intentional use of the JVM agent. However, the latter is indirect and may not be controlled by the connected 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。随着时间的推移，它正在成为技术债务，最终必须偿还。没有什么比因为不相关的原因而需要升级代码更有压力的了，而且您多年来依赖的一些已弃用的功能最终被删除，使得升级方式比需要的更加复杂。

The above is the detailed content of Stop messing around, these features will be deprecated and removed in Java 21!. For more information, please follow other related articles on the PHP Chinese website!