0Pricing
Java Academy · Lezione

Perché FFM invece di JNI

Interoperabilità nativa più sicura

Perché FFM invece di JNI è una lezione Java Academy gratuita su CoddyKit. Questa è la lezione 1 di 4. Puoi leggere la lezione completa qui gratuitamente — poi esercitati direttamente nel browser con un editor di codice integrato e un tutor IA disponibile 24/7. Fa parte del percorso di apprendimento Java Academy, e i tuoi progressi si sincronizzano tra il web e l'app CoddyKit. Il corso Java Academy include 4 lezioni in totale.

Chiamare codice nativo

A volte Java deve chiamare librerie C o lavorare con memoria off-heap. Il metodo classico era la Java Native Interface (JNI). Il metodo moderno è la Foreign Function and Memory API (FFM), finalizzata in Java 22 (JEP 454).

Questa lezione spiega perché FFM è la scelta migliore.

Cosa richiedeva JNI

JNI era complicato:

  • Scrivere codice di collegamento C con firme JNIEXPORT macchinose
  • Compilare una libreria nativa condivisa per ogni piattaforma
  • Convertire manualmente i tipi Java e C
  • Rischiare facilmente di arrestare la JVM per un errore

FFM è interamente Java

FFM consente di chiamare funzioni native e accedere alla memoria nativa interamente da Java. Niente codice di collegamento C, nessun passaggio di compilazione separato e nessun marshalling scritto a mano.

Si descrive la firma della funzione nativa in Java e la si invoca tramite un method handle.

I package principali

Tutto si trova in java.lang.foreign. I tipi principali sono:

  • Linker e SymbolLookup per trovare e collegare le funzioni
  • MemorySegment per la memoria nativa
  • Arena per una durata di vita deterministica
  • MemoryLayout e FunctionDescriptor per descrivere le strutture

Sicurezza fin dalla progettazione

FFM è molto più sicuro di JNI:

  • Accesso alla memoria con controllo dei limiti
  • Durata legata a un Arena, quindi l'uso dopo la liberazione viene rilevato
  • Il confinamento impedisce l'accesso non sicuro da thread diversi

Gli errori generano eccezioni Java anziché causare il crash della VM.

Un assaggio dell'API

Questo schema individua la funzione C strlen e prepara un handle per essa. Il punto è che si tratta interamente di normale codice Java.

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);
    }
}

Prestazioni

Le downcall di FFM offrono prestazioni paragonabili a JNI e spesso sono più veloci, perché il JIT può eseguire l'inlining e ottimizzare gli stub generati. Non è necessario attraversare un trampoline C a ogni chiamata.

Abilitazione dell'accesso nativo

Poiché il codice nativo può essere pericoloso, FFM può emettere un avviso o richiedere un opt-in esplicito. Si concede l'accesso all'avvio con --enable-native-access=ALL-UNNAMED (o con il nome di un modulo specifico) per eliminare gli avvisi.

Sostituire sun.misc.Unsafe

FFM (insieme alla Memory API) è anche la sostituzione ufficialmente supportata per le operazioni off-heap di sun.misc.Unsafe, da tempo deprecate. Le librerie che gestivano manualmente i buffer nativi possono migrare verso API sicure e supportate.

Strumenti: jextract

Per librerie C di grandi dimensioni, lo strumento complementare jextract legge un file di intestazione C e genera automaticamente i binding FFM Java. Non è necessario scrivere manualmente i descrittori.

È il corrispettivo di FFM per la produttività, proprio come un generatore di codice.

Quando usare FFM

Ricorra a FFM quando deve:

  • Chiamare una libreria C/C++ esistente
  • Interoperare con il sistema operativo a basso livello
  • Gestire in modo efficiente buffer off-heap

Per attività esclusivamente in Java, non ne ha mai bisogno.

Verifica rapida

Ricordi il principale vantaggio rispetto a JNI.

Riepilogo

Ha appreso perché FFM è migliore di JNI:

  • Solo Java, senza codice C di collegamento né compilazione aggiuntiva
  • Sicurezza garantita da controllo dei limiti, durata degli Arena e confinamento
  • Prestazioni paragonabili o superiori
  • Sostituisce sun.misc.Unsafe e si integra con jextract

Prossimo argomento: gestione della memoria nativa con MemorySegment e Arena.

Domande Frequenti

La lezione «Perché FFM invece di JNI» è gratuita?

Sì — il testo completo di «Perché FFM invece di JNI» è gratuito qui sul web. Per esercitarvi in modo interattivo (un editor di codice integrato e un tutor IA 24/7) e sbloccare il resto del corso Java Academy, passa a CoddyKit PRO. Il corso Java Academy include 4 lezioni in totale.

Cosa imparerò in «Perché FFM invece di JNI»?

Interoperabilità nativa più sicura Eserciti Java Academy con codice pratico che esegui direttamente nel browser, e un tutor IA 24/7 risponde alle tue domande mentre lavori sulla lezione.

Ho bisogno di esperienza per iniziare Java Academy?

Non è richiesta alcuna esperienza precedente. Java Academy su CoddyKit è strutturato per principianti e studenti avanzati, quindi puoi iniziare da qui o dall'inizio e procedere al tuo ritmo. Questa è la lezione 1 di 4.

Quanto tempo richiede la lezione «Perché FFM invece di JNI»?

La maggior parte delle lezioni CoddyKit richiede circa 5–10 minuti. Ogni lezione è breve e interattiva, quindi fai progressi costanti e riprendi esattamente da dove hai lasciato su web e app.

Posso scrivere ed eseguire codice in questa lezione Java Academy?

Sì. Ogni lezione Java Academy include un editor di codice integrato, quindi scrivi ed esegui codice reale direttamente nel tuo browser e ricevi feedback istantaneo dall'IA — nessuna configurazione locale necessaria.

Tutte le lezioni di questo corso

  1. Perché FFM invece di JNI
  2. MemorySegment e Arena
  3. Handle per downcall
  4. Layout e struct
← Torna a Java Academy