Java Academy · Lección

Por qué FFM en lugar de JNI

Interoperabilidad nativa más segura

Por qué FFM en lugar de JNI es una lección gratuita de Java Academy en CoddyKit. Esta es la lección 1 de 4. Puedes leer la lección completa abajo gratuitamente — luego la practicas en el navegador con un editor de código integrado y un tutor de IA 24/7. Forma parte de la ruta de aprendizaje de Java Academy, y tu progreso se sincroniza en la web y la app de CoddyKit. El curso de Java Academy incluye 4 lecciones en total.

Llamar a código nativo

A veces Java necesita llamar a bibliotecas de C o trabajar con memoria fuera del heap. La forma clásica era la Java Native Interface (JNI). La forma moderna es la Foreign Function and Memory API (FFM), finalizada en Java 22 (JEP 454).

En esta lección se explica por qué FFM es la mejor opción.

Qué requería JNI

JNI resultaba complicado:

Escribir código de enlace en C con firmas JNIEXPORT poco prácticas
Compilar una biblioteca nativa compartida para cada plataforma
Convertir manualmente entre tipos de Java y C
Es fácil hacer que la JVM se bloquee por un error

FFM es Java puro

FFM permite llamar a funciones nativas y acceder a memoria nativa completamente desde Java. Sin código de enlace en C, sin un paso de compilación separado y sin tener que escribir manualmente el marshalling.

Describa la firma de la función nativa en Java e invoquela mediante un handle de método.

Paquetes clave

Todo se encuentra en java.lang.foreign. Los tipos principales son:

Linker y SymbolLookup para localizar y enlazar funciones
MemorySegment para la memoria nativa
Arena para gestionar un ciclo de vida determinista
MemoryLayout y FunctionDescriptor para describir estructuras

Más seguro por diseño

FFM es mucho más seguro que JNI:

Acceso a memoria con comprobación de límites
Vida útil vinculada a un Arena, por lo que se detecta el uso después de liberar la memoria
El confinamiento evita el acceso no seguro entre hilos

Los errores generan excepciones de Java en lugar de bloquear la VM.

Una muestra de la API

Este esquema busca la función C strlen y prepara un handle para ella. Lo importante es que todo esto es código Java convencional.

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

Rendimiento

Las llamadas downcall de FFM ofrecen un rendimiento comparable al de JNI y, a menudo, superior, porque el JIT puede insertar y optimizar los stubs generados. No es necesario atravesar un trampolín de C en cada llamada.

Habilitar el acceso nativo

Como el código nativo puede ser peligroso, FFM puede mostrar una advertencia o requerir una habilitación explícita. Puede conceder el acceso al iniciar la aplicación con --enable-native-access=ALL-UNNAMED (o con el nombre de un módulo específico) para silenciar las advertencias.

Sustituir sun.misc.Unsafe

FFM (junto con la Memory API) también es el reemplazo oficial de las operaciones off-heap de sun.misc.Unsafe, obsoletas desde hace mucho tiempo. Las bibliotecas que administraban manualmente los búferes nativos pueden migrar a API seguras y compatibles.

Herramientas: jextract

Para bibliotecas C grandes, la herramienta complementaria jextract lee un archivo de cabecera C y genera automáticamente los bindings de Java para FFM. Así se evita escribir los descriptores manualmente.

Es el complemento de productividad de FFM, de forma similar a un generador de código.

Cuándo usar FFM

Utilice FFM cuando necesite:

Llamar a una biblioteca existente de C/C++
Interoperar con el sistema operativo a bajo nivel
Administrar grandes búferes fuera del heap de forma eficiente

Para trabajar exclusivamente con Java, nunca lo necesitará.

Comprobación rápida

Recuerde la principal ventaja frente a JNI.

Resumen

Ha aprendido por qué FFM supera a JNI:

Java puro, sin código adhesivo en C ni compilación adicional
Seguridad: comprobación de límites, vidas útiles de los Arena y confinamiento
Rendimiento comparable o superior
Sustituye a sun.misc.Unsafe y se combina con jextract

A continuación: administrar memoria nativa con MemorySegment y Arena.

Preguntas frecuentes

¿La lección «Por qué FFM en lugar de JNI» es gratis?

Sí — el texto completo de «Por qué FFM en lugar de JNI» es gratis para leer aquí en la web. Para practicarla de forma interactiva (editor de código integrado y tutor de IA 24/7) y desbloquear el resto del curso de Java Academy, actualiza a CoddyKit PRO. El curso de Java Academy incluye 4 lecciones en total.

¿Qué aprenderé en «Por qué FFM en lugar de JNI»?

Interoperabilidad nativa más segura Practicas Java Academy con código real que ejecutas directamente en el navegador, y un tutor de IA 24/7 responde tus preguntas mientras trabajas en la lección.

¿Necesito experiencia previa para empezar Java Academy?

No se requiere experiencia previa. Java Academy en CoddyKit está estructurado para principiantes hasta estudiantes avanzados, así que puedes empezar aquí o desde el inicio y avanzar a tu ritmo. Esta es la lección 1 de 4.

¿Cuánto tiempo toma la lección «Por qué FFM en lugar de JNI»?

La mayoría de las lecciones de CoddyKit toman alrededor de 5–10 minutos. Cada una es compacta e interactiva, así que avanzas constantemente y retomas exactamente por donde dejaste en la web y la app.

¿Puedo escribir y ejecutar código en esta lección de Java Academy?

Sí. Cada lección de Java Academy incluye un editor de código integrado, así que escribes y ejecutas código real directamente en tu navegador y obtienes retroalimentación instantánea de IA — sin configuración local necesaria.

Todas las lecciones de este curso

← Volver a Java Academy