더 이상 장난하지 마세요. 이러한 기능은 Java 21에서 더 이상 사용되지 않고 제거됩니다!

Java는 제가 사용해 본 언어 및 환경 중 가장 이전 버전과 호환되는 언어 중 하나이지만, 기능이 더 이상 사용되지 않거나 심지어 제거될 가능성도 항상 있습니다. Java 21에서는 두 가지 기능이 더 이상 사용되지 않으며 오늘 우리가 이에 대해 이야기하겠습니다.

1 기능을 더 이상 사용하지 않는 이유는 무엇입니까?

더 이상 사용되지 않는 코드나 기능은 해당 코드나 기능의 사용이 권장되지 않으며 향후 버전에서는 더 이상 존재하지 않을 수 있음을 의미합니다. 권장되지 않는 데에는 여러 가지 이유가 있을 수 있습니다.

지원 중단의 가장 일반적인 이유는 다음과 같습니다.

• 더 나은 대안으로 대체되었습니다.
• 설계상의 결함이 있어 사용하기에 위험할 수도 있습니다. 그러나 이전 버전과의 호환성으로 인해 즉시 또는 전혀 제거할 수 없습니다.
• 중복된 것으로 간주되므로 시스템과 사용 방법을 단순화하기 위해 제거해야 합니다.
• 향후 업데이트로 인해 이전 기능/코드를 지원하는 것이 불가능하거나 비현실적으로 될 것입니다.

근본 원인에 관계없이 더 이상 사용되지 않는 기능은 여전히 ​​시스템의 일부이므로 적어도 지금은 계속 사용할 수 있습니다.

Windows 32비트 x86 포트 지원 중단

JEP449는 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... 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-port=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.

가상 스레드 대 커널 스레드

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 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 중국어 웹사이트의 기타 관련 기사를 참조하세요!