# Java 25 Ostrzeżenia o wycofanych API na RHEL 9.7
Po aktualizacji do Java 25 na RHEL 9.7, IronPDF for Java rejestruje ostrzeżenia o wycofanych API odnoszące się do wewnętrznych API Javy takich jak `sun.misc.Unsafe::allocateMemory`. Generowanie PDF nadal działa; ostrzeżenia mają charakter informacyjny, ale mogą wzbudzać obawy dotyczące zgodności w regulowanych srodowiskach.
Ostrzeżenia pochodzą z bibliotek transportowych gRPC/Netty, które IronPDF używa wewnętrznie, a nie z własnego kodu IronPDF. Te biblioteki nadal wywołują `sun.misc.Unsafe` do bezpośredniego dostępu do pamięci. Java 23 wycofała metody dostępu do pamięci `sun.misc.Unsafe` do usunięcia (JEP 471), a Java 24 i nowsze ostrzegają, gdy są używane (JEP 498), dlatego teraz pojawiają się ostrzeżenia.
## Rozwiązanie
### 1. Potwierdź, że ostrzeżenia nie są blokujące
Sprawdź, czy renderowanie nadal się udaje przed wprowadzeniem jakichkolwiek zmian. Wiadomości to ostrzeżenia, nie błędy, a żadne problemy w czasie działania nie zostały zaobserwowane. Funkcje generowania PDF działają zgodnie z oczekiwaniami, więc usuwasz szum, nie naprawiasz usterki.
### 2. Dodaj flagi dostępu do argumentów startowych JVM
Przekaż te opcje podczas uruchamiania aplikacji, aby JVM otworzyła wewnętrzny pakiet wymagany przez biblioteki transportowe:
```bash
--enable-native-access=ALL-UNNAMED
--sun-misc-unsafe-memory-access=allow
```
Pierwsza flaga pozwala na natywny dostęp dla nieznanych modułów; druga ponownie włącza API pamięci `sun.misc.Unsafe`, od których zależy stos gRPC/Netty. Żadna z nich nie zmienia zachowania IronPDF; razem tłumią ostrzeżenia o wycofaniu.
[[w:(Te flagi są tymczasowym złagodzeniem, a nie trwałym rozwiązaniem. Długoterminowym rozwiązaniem jest aktualizacja dołączonych bibliotek gRPC/Netty do wersji, które nie zależą już od sun.misc.Unsafe. Przyszłe wydania Javy mogą jeszcze bardziej zaostrzyć egzekwowanie i złamać to obejście.)]]
Po aktualizacji do Java 25 na RHEL 9.7, IronPDF for Java rejestruje ostrzeżenia o wycofanych API odnoszące się do wewnętrznych API Javy takich jak sun.misc.Unsafe::allocateMemory. Generowanie PDF nadal działa; ostrzeżenia mają charakter informacyjny, ale mogą wzbudzać obawy dotyczące zgodności w regulowanych srodowiskach.
Ostrzeżenia pochodzą z bibliotek transportowych gRPC/Netty, które IronPDF używa wewnętrznie, a nie z własnego kodu IronPDF. Te biblioteki nadal wywołują sun.misc.Unsafe do bezpośredniego dostępu do pamięci. Java 23 wycofała metody dostępu do pamięci sun.misc.Unsafe do usunięcia (JEP 471), a Java 24 i nowsze ostrzegają, gdy są używane (JEP 498), dlatego teraz pojawiają się ostrzeżenia.
Rozwiązanie
1. Potwierdź, że ostrzeżenia nie są blokujące
Sprawdź, czy renderowanie nadal się udaje przed wprowadzeniem jakichkolwiek zmian. Wiadomości to ostrzeżenia, nie błędy, a żadne problemy w czasie działania nie zostały zaobserwowane. Funkcje generowania PDF działają zgodnie z oczekiwaniami, więc usuwasz szum, nie naprawiasz usterki.
2. Dodaj flagi dostępu do argumentów startowych JVM
Przekaż te opcje podczas uruchamiania aplikacji, aby JVM otworzyła wewnętrzny pakiet wymagany przez biblioteki transportowe:
Pierwsza flaga pozwala na natywny dostęp dla nieznanych modułów; druga ponownie włącza API pamięci sun.misc.Unsafe, od których zależy stos gRPC/Netty. Żadna z nich nie zmienia zachowania IronPDF; razem tłumią ostrzeżenia o wycofaniu.
Ostrzeżenie: Te flagi są tymczasowym złagodzeniem, a nie trwałym rozwiązaniem. Długoterminowym rozwiązaniem jest aktualizacja dołączonych bibliotek gRPC/Netty do wersji, które nie zależą już od sun.misc.Unsafe. Przyszłe wydania Javy mogą jeszcze bardziej zaostrzyć egzekwowanie i złamać to obejście.
Curtis Chau posiada tytuł licencjata z informatyki (Uniwersytet Carleton) i specjalizuje się w front-endowym rozwoju, z ekspertką w Node.js, TypeScript, JavaScript i React. Pasjonuje się tworzeniem intuicyjnych i estetycznie przyjemnych interfejsów użytkownika, Curtis cieszy się pracą z nowoczesnymi frameworkami i tworzeniem dobrze zorganizowanych, atrakcyjnych wizualnie podręczników.
