# Java 25 Abgekündigte-API-Warnungen auf RHEL 9.7
Nach der Aktualisierung auf Java 25 auf RHEL 9.7 protokolliert IronPDF for Java abgekündigte-API-Warnungen, die sich auf interne Java-APIs wie `sun.misc.Unsafe::allocateMemory` beziehen. PDF-Generierung funktioniert weiterhin; die Warnungen sind informativ, können jedoch in regulierten Umgebungen Compliance-Bedenken hervorrufen.
Die Warnungen stammen von den gRPC/Netty-Transportbibliotheken, die IronPDF intern verwendet, nicht aus eigenem Code von IronPDF. Diese Bibliotheken rufen weiterhin `sun.misc.Unsafe` für direkten Speicherzugriff auf. Java 23 hat die `sun.misc.Unsafe` Speicherzugriffsmethoden zur Entfernung als veraltet markiert (JEP 471), und Java 24 und spätere Versionen warnen, wenn sie verwendet werden (JEP 498), weshalb die Warnungen jetzt auftauchen.
## Lösung
### 1. Bestätigen, dass die Warnungen nicht blockierend sind
Prüfen Sie, dass das Rendering weiterhin erfolgreich ist, bevor Sie Änderungen vornehmen. Die Nachrichten sind Warnungen, keine Fehler, und es wurden keine Laufzeitprobleme beobachtet. Die PDF-Generierung funktioniert wie erwartet, daher beseitigen Sie Lärm, beheben aber keinen Fehler.
### 2. Fügen Sie die Zugriffsflags zu Ihren JVM-Startargumenten hinzu
Geben Sie diese Optionen an, wenn Sie Ihre Anwendung starten, damit die JVM das interne Paket öffnet, das die Transportbibliotheken benötigen:
```bash
--enable-native-access=ALL-UNNAMED
--sun-misc-unsafe-memory-access=allow
```
Das erste Flag erlaubt nativen Zugriff für unbenannte Module; das zweite aktiviert die `sun.misc.Unsafe` Speicher-API, von der der gRPC/Netty-Stack abhängt, erneut. Keines ändert das Verhalten von IronPDF; gemeinsam unterdrücken sie die Abkündigungswarnungen.
[[w:(Diese Flags sind eine interimistische Maßnahme, keine dauerhafte Lösung. Die langfristige Lösung besteht darin, die gebündelten gRPC/Netty-Bibliotheken auf Versionen zu aktualisieren, die nicht mehr auf sun.misc.Unsafe angewiesen sind. Zukünftige Java-Versionen könnten die Durchsetzung weiter verschärfen und dieses Workaround brechen.)]]
Nach der Aktualisierung auf Java 25 auf RHEL 9.7 protokolliert IronPDF for Java abgekündigte-API-Warnungen, die sich auf interne Java-APIs wie sun.misc.Unsafe::allocateMemory beziehen. PDF-Generierung funktioniert weiterhin; die Warnungen sind informativ, können jedoch in regulierten Umgebungen Compliance-Bedenken hervorrufen.
Die Warnungen stammen von den gRPC/Netty-Transportbibliotheken, die IronPDF intern verwendet, nicht aus eigenem Code von IronPDF. Diese Bibliotheken rufen weiterhin sun.misc.Unsafe für direkten Speicherzugriff auf. Java 23 hat die sun.misc.Unsafe Speicherzugriffsmethoden zur Entfernung als veraltet markiert (JEP 471), und Java 24 und spätere Versionen warnen, wenn sie verwendet werden (JEP 498), weshalb die Warnungen jetzt auftauchen.
Lösung
1. Bestätigen, dass die Warnungen nicht blockierend sind
Prüfen Sie, dass das Rendering weiterhin erfolgreich ist, bevor Sie Änderungen vornehmen. Die Nachrichten sind Warnungen, keine Fehler, und es wurden keine Laufzeitprobleme beobachtet. Die PDF-Generierung funktioniert wie erwartet, daher beseitigen Sie Lärm, beheben aber keinen Fehler.
2. Fügen Sie die Zugriffsflags zu Ihren JVM-Startargumenten hinzu
Geben Sie diese Optionen an, wenn Sie Ihre Anwendung starten, damit die JVM das interne Paket öffnet, das die Transportbibliotheken benötigen:
Das erste Flag erlaubt nativen Zugriff für unbenannte Module; das zweite aktiviert die sun.misc.Unsafe Speicher-API, von der der gRPC/Netty-Stack abhängt, erneut. Keines ändert das Verhalten von IronPDF; gemeinsam unterdrücken sie die Abkündigungswarnungen.
Warnung: Diese Flags sind eine interimistische Maßnahme, keine dauerhafte Lösung. Die langfristige Lösung besteht darin, die gebündelten gRPC/Netty-Bibliotheken auf Versionen zu aktualisieren, die nicht mehr auf sun.misc.Unsafe angewiesen sind. Zukünftige Java-Versionen könnten die Durchsetzung weiter verschärfen und dieses Workaround brechen.
Curtis Chau hat einen Bachelor-Abschluss in Informatik von der Carleton University und ist spezialisiert auf Frontend-Entwicklung mit Expertise in Node.js, TypeScript, JavaScript und React. Leidenschaftlich widmet er sich der Erstellung intuitiver und ästhetisch ansprechender Benutzerschnittstellen und arbeitet gerne mit modernen Frameworks sowie der Erstellung gut strukturierter, optisch ansprechender Handbücher.
