Java Academy · Lekcja

Dlaczego FFM zamiast JNI

Bezpieczniejsza współpraca z kodem natywnym

Dlaczego FFM zamiast JNI to bezpłatna lekcja Java Academy na CoddyKit. To lekcja 1 z 4. Możesz przeczytać całą lekcję poniżej za darmo — a potem ćwiczyć ją interaktywnie w przeglądarce z wbudowanym edytorem kodu i tutorem AI dostępnym 24/7. To część ścieżki edukacyjnej Java Academy, a Twój postęp synchronizuje się między webem a aplikacją CoddyKit. Kurs Java Academy zawiera 4 lekcji w sumie.

Wywoływanie kodu natywnego

Java czasami musi wywoływać biblioteki C lub pracować z pamięcią poza stertą. Klasycznym rozwiązaniem był Java Native Interface (JNI). Nowoczesnym rozwiązaniem jest Foreign Function and Memory API (FFM), sfinalizowane w Javie 22 (JEP 454).

W tej lekcji wyjaśniono, dlaczego FFM jest lepszym wyborem.

Czego wymagało JNI

Korzystanie z JNI było uciążliwe:

Należało pisać kod pośredniczący w C z nieporęcznymi sygnaturami JNIEXPORT
Należało kompilować natywną bibliotekę współdzieloną osobno dla każdej platformy
Należało ręcznie konwertować typy między Javą a C
Pomyłka mogła łatwo doprowadzić do awarii JVM

FFM jest napisane w całości w Javie

FFM umożliwia wywoływanie funkcji natywnych i dostęp do pamięci natywnej wyłącznie z poziomu Javy. Nie potrzeba kodu pośredniczącego w C, osobnego etapu kompilacji ani ręcznie pisanego marshalingu.

Sygnaturę funkcji natywnej opisuje się w Javie, a następnie wywołuje ją za pośrednictwem uchwytu metody.

Najważniejsze pakiety

Wszystko znajduje się w pakiecie java.lang.foreign. Najważniejsze typy to:

Linker i SymbolLookup do wyszukiwania funkcji i tworzenia ich powiązań
MemorySegment do obsługi pamięci natywnej
Arena do deterministycznego zarządzania czasem życia
MemoryLayout i FunctionDescriptor do opisywania struktur danych

Bezpieczniej już na etapie projektowania

FFM jest znacznie bezpieczniejsze niż JNI:

Dostęp do pamięci z kontrolą zakresu
Czas życia powiązany z obiektem Arena, dzięki czemu użycie po zwolnieniu pamięci zostaje wykryte
Izolacja zapobiega niebezpiecznemu dostępowi z innych wątków

Błędy powodują zgłoszenie wyjątków Javy zamiast awarii maszyny wirtualnej.

Przedsmak API

Ten przykład wyszukuje funkcję C strlen i przygotowuje uchwyt do niej. Najważniejsze jest to, że cały kod jest zwykłym kodem Javy.

import java.lang.foreign.*;
import java.lang.invoke.MethodHandle;

public class Main {
    public static void main(String[] args) {
        Linker linker = Linker.nativeLinker();
        SymbolLookup stdlib = linker.defaultLookup();
        MethodHandle strlen = linker.downcallHandle(
            stdlib.find("strlen").orElseThrow(),
            FunctionDescriptor.of(ValueLayout.JAVA_LONG, ValueLayout.ADDRESS));
        System.out.println("Bound a handle to strlen: " + strlen);
    }
}

Wydajność

Wywołania downcall FFM dorównują JNI, a często są szybsze, ponieważ JIT może wbudować i zoptymalizować wygenerowane stuby. Nie ma osobnego trampolinu C do przekraczania przy każdym wywołaniu.

Włączanie dostępu do kodu natywnego

Ponieważ kod natywny może być niebezpieczny, FFM może wyświetlać ostrzeżenia lub wymagać wyraźnej zgody. Dostęp przy uruchamianiu przyznaje się za pomocą --enable-native-access=ALL-UNNAMED (lub nazwy konkretnego modułu), aby wyciszyć ostrzeżenia.

Zastępowanie sun.misc.Unsafe

FFM (wraz z Memory API) jest również oficjalnie zalecanym zamiennikiem od dawna przestarzałych operacji poza stertą z użyciem sun.misc.Unsafe. Biblioteki, które ręcznie zarządzały natywnymi buforami, mogą przejść na bezpieczne i wspierane API.

Narzędzie: jextract

W przypadku dużych bibliotek C dołączone narzędzie jextract odczytuje plik nagłówkowy C i automatycznie generuje powiązania Java FFM. Nie trzeba ręcznie pisać deskryptorów.

Jest to odpowiednik FFM zwiększający produktywność, podobnie jak generator kodu.

Kiedy używać FFM

Warto sięgnąć po FFM, gdy trzeba:

Wywoływać istniejącą bibliotekę C/C++
Współpracować z systemem operacyjnym na niskim poziomie
Wydajnie zarządzać dużymi buforami poza stertą

W przypadku pracy wyłącznie w Javie nigdy nie jest ono potrzebne.

Szybkie sprawdzenie

Proszę przypomnieć sobie najważniejszą przewagę nad JNI.

Podsumowanie

Dowiedzieli się Państwo, dlaczego FFM przewyższa JNI:

Czysta Java, bez kodu pośredniczącego w C i dodatkowej kompilacji
Bezpieczeństwo: kontrola zakresu, czas życia obiektów Arena i izolacja
Porównywalna lub lepsza wydajność
Zastępuje sun.misc.Unsafe i współpracuje z jextract

Następnie: zarządzanie pamięcią natywną za pomocą MemorySegment i Arena.

Często zadawane pytania

Czy lekcja „Dlaczego FFM zamiast JNI” jest bezpłatna?

Tak — pełny tekst „Dlaczego FFM zamiast JNI” jest dostępny za darmo tutaj w sieci. Aby ćwiczyć ją interaktywnie (wbudowany edytor kodu i tutor AI dostępny 24/7) i odblokować resztę kursu Java Academy, przejdź na CoddyKit PRO. Kurs Java Academy zawiera 4 lekcji w sumie.

Co nauczysz się w „Dlaczego FFM zamiast JNI”?

Bezpieczniejsza współpraca z kodem natywnym Ćwiczysz Java Academy z praktycznym kodem, który uruchamiasz bezpośrednio w przeglądarce, a tutor AI dostępny 24/7 odpowiada na Twoje pytania podczas pracy nad lekcją.

Czy potrzebuję doświadczenia, aby zacząć Java Academy?

Nie wymagamy żadnego doświadczenia. Java Academy w CoddyKit jest strukturyzowany dla początkujących i zaawansowanych użytkowników, więc możesz zacząć tutaj lub od początku i uczyć się w swoim tempie. To lekcja 1 z 4.

Ile czasu zajmuje lekcja „Dlaczego FFM zamiast JNI”?

Większość lekcji CoddyKit trwa około 5–10 minut. Każda lekcja to mały, interaktywny krok, dzięki czemu robisz systematyczne postępy i zawsze wracasz dokładnie do tego samego miejsca — na webie i w aplikacji.

Czy mogę pisać i uruchamiać kod w tej lekcji Java Academy?

Tak. Każda lekcja Java Academy zawiera wbudowany edytor kodu, więc piszesz i uruchamiasz prawdziwy kod bezpośrednio w przeglądarce i od razu otrzymujesz sprzężenie zwrotne od AI — bez konfiguracji na komputerze.

Wszystkie lekcje w tym kursie

← Powrót do Java Academy