Java 21 终于对这些功能动刀了！！
来源：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最新版）
觉得不错，别忘了随手点赞+转发哦！
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。
页:
[1]