IronPDF for Java: How to Address Java 25 Deprecated Warnings for RHEL 9.7 Deployments

Overview

This article explains why IronPDF for Java emits deprecated-API warnings after upgrading to Java 24 or 25 on RHEL 9.7, and how to suppress them with a JVM flag. The warnings originate in an upstream dependency, not in IronPDF's own code, so no IronPDF code change can remove them — this article covers the root cause, the mitigation, and how to respond if a customer asks about a permanent fix.

Version Metadata

• Minimum Version: N/A
• Superseded-in Version: N/A

Steps

1. Confirm the warnings are non-blocking. The deprecated-API warnings come from the gRPC/Netty transport libraries that IronPDF for Java uses internally — not from IronPDF's own code. They reference internal Java APIs such as sun.misc.Unsafe::allocateMemory. PDF generation continues to work normally, so these are warnings rather than errors.
2. Understand where the warning comes from. IronPDF for Java never calls sun.misc.Unsafe directly. It opens a gRPC channel; gRPC uses the shaded Netty transport (grpc-netty-shaded), and Netty 4.1.x uses sun.misc.Unsafe for off-heap memory allocation. Starting with Java 24, the JDK prints a warning the first time these legacy memory-access methods are used. PDF generation is unaffected, so these are warnings rather than errors. The call flow is:

   Our Application
          ↓
      IronPDF Java
          ↓
      gRPC (grpc-netty-shaded)
          ↓
      Netty
          ↓
      sun.misc.Unsafe
          ↓
      Java 24/25 prints a warning

    

3. Add the access flag to your JVM startup arguments. Pass the following options when launching your application so the JVM opens the internal package the transport libraries require:

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

   For example: java --sun-misc-unsafe-memory-access=allow -jar yourapp.jar

   This clears the deprecation warnings without changing IronPDF behaviour.

4. Alternative — force Netty to skip Unsafe entirely. If you prefer to disable Unsafe inside Netty rather than allow it at the JDK level, set:
   -Dio.grpc.netty.shaded.io.netty.noUnsafe=true
   Note that gRPC relocates io.netty to io.grpc.netty.shaded.io.netty, so the property must use the shaded name io.grpc.netty.shaded.io.netty.noUnsafe — not the documented io.netty.noUnsafe. Using the unshaded name is the most common mistake and has no effect. This route may cost a small amount of off-heap performance, so --sun-misc-unsafe-memory-access=allow is generally the cleaner choice.

Notes and Limitations

• No runtime issues have been observed. PDF generation functions as expected, so the warnings are informational.
• The warning originates inside Netty, not IronPDF. Changing IronPDF's source code cannot eliminate it while the current grpc-netty-shaded dependency is in use.
• There is no permanent fix available yet. The warning will only disappear once grpc-java adopts Netty 4.2 or later — which replaces sun.misc.Unsafe with modern memory APIs — and IronPDF picks up that release. That upstream release has not shipped, so for now the JVM flag is the only option.
• The alternative noUnsafe property may cost a small amount of off-heap performance, which is why the JDK flag is preferred.