1. IronPDF
  2. 故障排除
  3. Java 25 在 RHEL 9.7 上的已废弃 API 警告

Java 25 在 RHEL 9.7 上的已弃用 API 警告

Curtis Chau
Curtis Chau
已更新:
This article was translated from English: Does it need improvement?
Translated
View the article in English

升级到 RHEL 9.7 上的 Java 25 后，IronPDF for Java 会记录引用内部 Java API 的已弃用 API 警告，例如 sun.misc.Unsafe::allocateMemory。 PDF 生成保持正常工作； 这些警告是信息性的，但在受监管环境中可能会引发合规问题。

这些警告来自 IronPDF 内部使用的 gRPC/Netty 传输库，而非 IronPDF 自身的代码。 这些库仍调用 sun.misc.Unsafe 来进行直接内存访问。 Java 23 已弃用了用于移除的 sun.misc.Unsafe 内存访问方法（JEP 471），而 Java 24 及以后在使用时会发出警告（JEP 498），这就是现在警告显现的原因。

解决方案

1. 确认警告不会阻碍运行

在更改任何内容之前，检查渲染是否仍然成功。 这些消息是警告而不是错误，并未观察到运行时问题。 PDF 生成功能如预期般运行，因此您是在清除噪音，而不是修复故障。

2. 将访问标志添加到您的 JVM 启动参数中

启动应用程序时传递这些选项，以便 JVM 打开传输库所需的内部包：

--enable-native-access=ALL-UNNAMED
--sun-misc-unsafe-memory-access=allow
--enable-native-access=ALL-UNNAMED
--sun-misc-unsafe-memory-access=allow
SHELL

第一个标志允许未命名模块的本地访问； 第二个则重新启用 gRPC/Netty 栈所依赖的 sun.misc.Unsafe 内存 API。 两者都不改变 IronPDF 的行为； 它们一起抑制了弃用警告。

警告这些标志是临时缓解措施，而不是永久解决方案。 长期解决方案是将捆绑的 gRPC/Netty 库更新到不再依赖 sun.misc.Unsafe 的版本。 未来的 Java 发行版可能会进一步加强执行并破坏此变通方法。

Curtis Chau
Curtis Chau
  立即与工程团队聊天
技术作家

Curtis Chau 拥有卡尔顿大学的计算机科学学士学位，专注于前端开发，精通 Node.js、TypeScript、JavaScript 和 React。他热衷于打造直观且美观的用户界面，喜欢使用现代框架并创建结构良好、视觉吸引力强的手册。

除了开发之外，Curtis 对物联网 (IoT) 有浓厚的兴趣，探索将硬件和软件集成的新方法。在空闲时间，他喜欢玩游戏和构建 Discord 机器人，将他对技术的热爱与创造力相结合。

准备开始了吗？
版本: 2026.6 刚刚发布
Still Scrolling Icon

还在滚动吗？

想快速获得证据？
运行示例看着你的HTML代码变成PDF文件。