JNI vs FFM API:

La Revolución de la Interoperabilidad Nativa

Análisis técnico exhaustivo de las diferencias estructurales, modelo de seguridad, gestión de memoria y métricas de rendimiento entre JNI y la Foreign Function & Memory API en JDK 25. Guía definitiva para arquitectos de software.

La Máquina Virtual de Java lleva más de tres décadas manteniendo su promesa de Write Once, Run Anywhere. Pero esa promesa siempre tuvo una fisura: el código Java que necesita hablar con bibliotecas nativas escritas en C, C++ o Rust. Durante 27 años, ese puente se llamó JNI (Java Native Interface), introducido en JDK 1.1. Y durante esos 27 años, acumuló una deuda técnica monumental.

Con JDK 25 (GA: 16 de septiembre de 2025), la historia cambia definitivamente. La Foreign Function & Memory API (FFM), gestada en el Proyecto Panama e incubada durante años, alcanza madurez operativa plena como parte de Java SE 25. No es una mejora incremental sobre JNI: es un reemplazo arquitectónico completo que transforma la forma en que la JVM interactúa con el sistema nativo.

Este artículo disecciona ambas tecnologías con la profundidad que merece una decisión arquitectónica de esta magnitud.

La deuda técnica de JNI: tres décadas de fricción

Para apreciar la magnitud del cambio que introduce FFM, es necesario entender exactamente por qué JNI se convirtió en un obstáculo.

El problema del toolchain dual

Integrar cualquier biblioteca C mediante JNI no es un proceso natural dentro del ecosistema Java. El flujo exige:

1. Declarar métodos con la palabra clave native en Java
2. Ejecutar javac -h para generar headers .h en C
3. Escribir código “pegamento” (glue code) en C/C++ que desempaqueta los tipos opacos de la JVM (jstring, jobject, jint) y llama a la biblioteca objetivo
4. Compilar el artefacto nativo (.so, .dll, .dylib) con GCC o Clang, por plataforma y arquitectura
5. Integrar la compilación nativa en Maven/Gradle

Esta fragmentación rompe la portabilidad del proyecto y multiplica la carga operativa por cada combinación de OS/arquitectura que se quiera soportar.

El punto ciego del JIT

Cada vez que un hilo JVM invoca un método JNI, debe ejecutar una transición de estado desde _thread_in_Java hacia _thread_in_native. Para el compilador C2 de HotSpot, un método JNI es una caja negra impenetrable: el inlining, el escape analysis y el constant folding se detienen abruptamente en esa frontera. El JIT no puede optimizar lo que no puede ver.

Interferencia con el Garbage Collector

La interacción de JNI con el GC es el problema más grave para aplicaciones de baja latencia. Cuando el código nativo necesita acceder a arrays de primitivas de Java, típicamente invoca GetPrimitiveArrayCritical, que ancla (pins) el array en memoriapara que el GC no lo mueva. Este anclaje degrada o paraliza los algoritmos modernos de recolección, generando latencias impredecibles que destruyen SLAs.

⚠ VULNERABILIDAD CWE-111

OWASP cataloga el uso directo de JNI bajo CWE-111 (Direct Use of Unsafe JNI). Un método nativo invocado desde Java que use gets() en C puede exponer toda la aplicación a buffer overflow, incluso si la capa Java está diseñada impecablemente. El contrato de seguridad de la JVM no puede extenderse más allá de sus fronteras.

Violación del modelo de objetos

El código nativo puede usar la interfaz JNI para inspeccionar o modificar campos privados de clases Java, mutar instancias de String(teóricamente inmutables), y ejecutar todo esto sin que la JVM ejecute ninguna comprobación de acceso. El resultado: comportamientos indefinidos imposibles de rastrear.

Arquitectura FFM API: los cinco pilares

La FFM API, estandarizada en el paquete java.lang.foreign, desacopla conceptualmente la gestión de memoria y la invocación de funciones mediante cinco abstracciones que la JVM puede optimizar directamente:

MemorySegment reemplaza al problemático ByteBuffer y al uso de punteros crudos vía sun.misc.Unsafe. Modela una región contigua que puede estar tanto en el heap como off-heap, con verificación de límites espaciales en tiempo real.

Arena controla el ciclo de vida de los segmentos. Transfiere la responsabilidad de liberar memoria desde el GC hacia un determinismo explícito controlado por el flujo de ejecución del programa. Desde JDK 22 (JEP 454), los segmentos asignados por arenas están zero-initialized por especificación. En JDK 25, la implementación de la rutina de zeroing fue optimizada significativamente (JDK-8345687).

Linker es el mediador entre Java y las funciones foráneas. Conoce en profundidad la ABI de la plataforma (System V en Linux/x64, ABI de Windows/x64) y genera downcall stubs que el compilador JIT puede introspeccionar y optimizar.

SymbolLookup resuelve nombres de funciones C a sus direcciones en memoria, como un linker dinámico programático.

FunctionDescriptor elimina los archivos .h de C. Describe en Java puro la firma de una función nativa usando abstracciones tipadas (ValueLayout.JAVA_INT, ValueLayout.ADDRESS, etc.).

✓ VENTAJA ARQUITECTÓNICA CLAVE

A diferencia de JNI, donde el compilador JIT topa con una pared opaca, los MethodHandle generados por el Linker de FFM son transparentes para C2. En bucles calientes, el compilador genera downcall stubs hiperoptimizados con constant folding del descriptor, eliminando toda la sobrecarga de frame setup de JNI.

Gestión de memoria off-heap y ciclos de vida

En sistemas de alto rendimiento (HFT, bases de datos in-memory, motores de mensajería), las pausas del GC son el enemigo número uno. FFM permite manipular gigabytes de memoria sin involucrar en absoluto al recolector, con seguridad garantizada.

En JDK 25, la optimización JDK-8345687 reformuló la implementación de SegmentFactories::allocateSegment, logrando hasta un 2x de aceleración en asignación off-heap respecto a JDK 24. Los detalles se expanden en la sección Cambios específicos de JDK 25.

Benchmarks de rendimiento con JMH

Sustituir JNI solo tiene sentido si los números lo respaldan. Los benchmarks JMH revelan un patrón dicotómico fascinante:

El patrón se puede resumir en dos principios:

Principio del “Bulk Work” — el poder real de FFM

En el benchmark de multiplicación de matrices BLAS (1024×1024, 2 mil millones de operaciones en punto flotante), delegar a la biblioteca nativa mediante FFM completó la tarea en 9 ms. La rutina Java pura tardó 1.978 ms. Una aceleración de 220x. El costo de cruzar la frontera mediante el Linker se diluye hasta la irrelevancia frente a la velocidad de ejecución vectorizada SIMD del procesador.

Anti-patrón: los “Upcalls Charlatanes”

El contraejemplo es categórico: ordenar 10 millones de enteros con qsort de libc usando un comparador Java (upcall) tardó 16.965 ms. El mismo trabajo con Arrays.sort: 686 ms. Cada comparación exigía una transición C→JVM que, acumulada millones de veces, castigó el rendimiento de forma insalvable.

REGLA DE DISEÑO FFM

Maximiza el trabajo por cruce de frontera. FFM brilla cuando se delega trabajo masivo a código nativo. Se degrada cuando el código nativo necesita regresar frecuentemente a Java para ejecutar lógica. Diseña el sistema para que C realice ciclos completos de procesamiento, no para que C y Java se llamen mutuamente en bucles internos.

Seguridad e Integridad por Defecto (JEP 472)

JEP 472: Prepare to Restrict the Use of JNI, introducido en JDK 24 y vigente en JDK 25, establece un ultimátum arquitectónico. Antes de JDK 24, cualquier módulo podía invocar System.loadLibrary()silenciosamente. Ahora, toda interacción foránea se cataloga como Restringida. Adicionalmente, JDK 24 introduce la herramienta jnativescan, que escanea estáticamente el classpath/module path y reporta métodos native y uso de APIs restringidas — esencial para auditorías de migración.

Para habilitar acceso nativo en producción:

# Módulo específico (recomendado para producción)
java --enable-native-access=com.mycompany.nativelib ...

# Todos los módulos sin nombre (migración / legacy)
java --enable-native-access=ALL-UNNAMED ...

# CI/CD: detectar dependencias JNI no declaradas
java --illegal-native-access=deny ...

# Auditar JARs con jnativescan (JDK 24+)
jnativescan --class-path libs/*.jar --print-native-access

O en el MANIFEST.MF del JAR:

Enable-Native-Access: ALL-UNNAMED

⚠ PROYECCIÓN OPERATIVA

Una futura versión de Java transicionará el comportamiento por defecto de “warn” a “deny”. Los proyectos que dependan de JNI sin --enable-native-access explícito fallarán con IllegalCallerException. Comienza la migración hoy usando --illegal-native-access=deny en tu pipeline de CI para detectar todas las dependencias transitivas.

Cambios específicos de JDK 25

Aunque FFM es API de producto desde JDK 22 (JEP 454), JDK 25 introduce refinamientos importantes:

1. Rendimiento de asignación en Arena (JDK-8345687)

La mejora más relevante de JDK 25 para FFM es el ticket JDK-8345687, que reformuló la implementación de SegmentFactories::allocateSegment, logrando hasta un 2x de aceleración en asignación off-heap. Los segmentos asignados por arenas ya estaban especificados como zero-initialized desde JEP 454 (JDK 22); la novedad de JDK 25 es que la rutina de zeroing es significativamente más rápida, con alineamiento explícito a la arquitectura del procesador y eliminación de asignaciones intermedias.

2. MemorySegment.reinterpret() como método restringido explícito

El diff de JDK 25 formaliza que reinterpret puede causar corrupción de memoria o VM crash si el tamaño o lifetime están mal especificados. Documentado con IllegalCallerException si el módulo no tiene native access habilitado.

3. firstVariadicArg() para funciones variádicas

Al enlazar funciones C declaradas como variádicas (e.g. printf, ioctl), especificar Linker.Option.firstVariadicArg(int) es obligatorio. El índice indica la posición del primer argumento variádico en el descriptor (base 0). Esto es necesario porque la calling convention puede diferir entre argumentos fijos y variádicos — especialmente en x64 con SystemV ABI, donde los variádicos usan registros distintos (e.g. AL para SSE). Incluso si en una invocación concreta no se pasan variádicos (e.g. printf("%s", str)), el linker necesita saber que la función es variádica. La regla formal es 0 ≤ index ≤ N donde N es el número de layouts en el descriptor.

4. Sinergia con JEP 502: Stable Values (Preview)

⚠ FEATURE EN PREVIEW

StableValue es una Preview API en JDK 25 (JEP 502). Requiere --enable-preview tanto para compilar como para ejecutar. Su API puede cambiar antes de ser finalizada en una versión futura. En JDK 26, esta API fue renombrada a ComputedConstant.

Esta es la sinergia más poderosa de JDK 25 para FFM. Un MethodHandle obtenido de Linker.downcallHandle() es un objeto pesado. Antes, cada acceso a él requería navegación en memoria. Con Stable Values:

// JDK 25: MethodHandle como constante de JIT via StableValue (Preview)
// Compilar: javac --release 25 --enable-preview ...
// Ejecutar: java --enable-preview ...
private static final StableValue<MethodHandle> STRLEN_MH =
    StableValue.of();

static {
    MethodHandle mh = Linker.nativeLinker().downcallHandle(
        SymbolLookup.loaderLookup().find("strlen").orElseThrow(),
        FunctionDescriptor.of(ValueLayout.JAVA_LONG, ValueLayout.ADDRESS)
    );
    STRLEN_MH.orElseSet(() -> mh); // Thread-safe, at-most-once; C2 trata como constante
}

La API de StableValue no tiene un método set(). La inicialización se realiza mediante orElseSet(Supplier) (lazy, thread-safe), trySet(T) (retorna boolean) o setOrThrow(T) (lanza excepción si ya está establecido). Para FFM, el patrón más idiomático es orElseSet.

El compilador C2 explota la inmutabilidad declarada con constant folding agresivo. Cuando el StableValue se almacena en un campo static final, todas las verificaciones en tiempo de ejecución desaparecen y la ruta al código C se reemplaza por direcciones de memoria empotradas directamente en el pipeline del procesador. El resultado: código Java/C que compite en latencia con ensamblador puro.

5. JEP 519: Compact Object Headers

Al comprimir las cabeceras de objetos a 64 bits en arquitecturas de 64 bits, las clases del ecosistema FFM son más livianas en el heap, minimizando cache misses al transicionar entre heap y off-heap.

6. JEP 521: Shenandoah Generacional (producto soportado)

Combinado con Arena.ofConfined() (zero-GC para memoria off-heap), Shenandoah generacional otorga tiempos de pausa marginales para la memoria on-heap. JDK 25 permite arquitecturas empresariales operando decenas de miles de TPS sin disrupciones sistémicas.

Comparativa de código: JNI vs FFM

El mismo ejemplo práctico en ambos paradigmas: llamar a strlen de libc.

EJEMPLO AVANZADO: STRUCT C CON FFM

// Mapeo de struct Point { int x; int y; } en Java puro
StructLayout POINT_LAYOUT = MemoryLayout.structLayout(
    ValueLayout.JAVA_INT.withName("x"),
    ValueLayout.JAVA_INT.withName("y")
).withName("Point");

VarHandle xHandle = POINT_LAYOUT.varHandle(
    MemoryLayout.PathElement.groupElement("x"));
VarHandle yHandle = POINT_LAYOUT.varHandle(
    MemoryLayout.PathElement.groupElement("y"));

try (Arena arena = Arena.ofConfined()) {
    MemorySegment point = arena.allocate(POINT_LAYOUT);
    xHandle.set(point, 0L, 42);   // point.x = 42
    yHandle.set(point, 0L, -7);   // point.y = -7

    // Llamar nativa que recibe Point*
    nativeFunc.invokeExact(point);
} // ← memoria liberada aquí, determinísticamente

jextract: eliminando el boilerplate

Para bibliotecas C grandes (cientos de funciones, structs complejos, typedefs dependientes de arquitectura), describir manualmente cada FunctionDescriptor y StructLayout sería una tarea colosal y propensa a errores.

La respuesta del ecosistema es jextract, una herramienta periférica del Proyecto Panama que usa internamente la API C del compilador Clang/LLVM para analizar archivos .h y generar automáticamente clases Java con todos los descriptores, layouts y MethodHandle:

# Ejemplo: generar bindings para OpenSSL
jextract \
  --target-package com.myapp.openssl \
  -l ssl \
  /usr/include/openssl/ssl.h

# Resultado: clases Java con todo preconfigurado
# SSL_CTX_new(), SSL_connect(), SSL_read()...
# ...como métodos Java tipados estáticamente

⚙ NOTA OPERATIVA

jextract no forma parte del JDK estándar. Se obtiene por separado desde jdk.java.net/jextract. El propio Javadoc de JDK 25 lo referencia como herramienta complementaria.

Adopción real: Lucene, Netty y zstd-jni

Apache Lucene 10.x / 11.x (en desarrollo)

El motor de búsqueda detrás de Elasticsearch y Apache Solr ha adoptado FFM de forma progresiva. En Lucene 9.0, la interfaz NativeUnixDirectory (que usaba JNI para operaciones de disco con Direct I/O) fue eliminada y reemplazada por DirectIODirectory, basada en FileChannel con ExtendedOpenOption.DIRECT del NIO de Java — aún sin FFM. La adopción real de FFM llegó con Lucene 10.x, donde MMapDirectory migró internamente a MemorySegment de la FFM API para mapeos de memoria, abandonando sun.misc.Unsafe y ByteBuffer. Adicionalmente, Lucene explota la Vector API (JEP 508, incubating) para vectorización SIMD en algoritmos de búsqueda léxica.

En febrero de 2025, se abrió una propuesta formal (GitHub issue #14229) para elevar el requisito mínimo de Java a JDK 25 en un futuro Lucene 11.0, que aún no ha sido liberado (a abril 2026, la última release estable es 10.4.x). La intención es explotar completamente las APIs de JDK 25 LTS, incluyendo Compact Object Headers y mejoras en el rendimiento de MemorySegment.

Netty 4.2

El framework de redes asíncrono de alto rendimiento realizó cambios significativos en su línea 4.2.x, incluyendo la graduación del transporte io_uring desde incubator a módulo soportado, un nuevo adaptive memory allocator como default, y la migración a módulos JPMS reales. Sin embargo, a la fecha, los transportes nativos de epoll y kqueueaún utilizan JNI para sus bindings nativos precompilados. La comunidad ha discutido la migración a FFM como objetivo futuro — motivada por las advertencias de JEP 472 y la simplificación del build cross-platform — pero esta transición no se ha completado en la línea 4.2.x. Netty sí ha experimentado con virtual threads y ha mejorado su integración con io_uring y transferencias Zero-Copy, posicionándose para una adopción gradual de FFM en versiones posteriores.

zstd-jni: el caso de advertencia

La biblioteca de compresión Zstandard para Java es un ejemplo de la presión que JEP 472 ejerce sobre proyectos JNI existentes. En JDK 25, los logs empresariales se inundan con advertencias de métodos restringidos. Adicionalmente, se han reportado inconsistencias funcionales y fallos de descompresión. Los mantenedores del proyecto open-source están bajo presión para migrar a FFM antes de que el comportamiento por defecto cambie a “deny”.

Estrategia de migración

Estrategia incremental (sin big bang)

1. Auditar el surface area nativo — identifica todos los System.loadLibrary() y métodos native. Con JEP 472, ejecutar con --illegal-native-access=warn te dará un inventario completo en los logs. La herramienta jnativescan (incluida desde JDK 24) puede escanear estáticamente JARs y module paths para reportar uso de métodos restringidos y declaraciones native sin necesidad de ejecutar la aplicación.
2. Crear wrappers FFM paralelos — para las funciones “hoja” (downcalls simples, structs/arrays planos). Mantén JNI para callbacks complejos mientras dominas FFM.
3. Migrar los data paths críticos — donde JNI hoy copia arrays/strings, prueba FFM con Arena.ofConfined() y layouts tipados.
4. Endurecer el pipeline CI/CD — ejecuta con --illegal-native-access=deny para anticipar el endurecimiento futuro y no quedar atrapado.

⚙ LIMITACIÓN: INTEROP C++

FFM opera exclusivamente sobre la C ABI de la plataforma. No puede enlazar directamente funciones C++ con name mangling, clases, templates o excepciones C++. Para bibliotecas C++, se requiere exponer una fachada extern "C" o seguir usando JNI, que sí soporta el JNI Invocation API con C++ directamente. Esto es relevante para integraciones con bibliotecas como TensorFlow C++, CUDA runtime, o cualquier SDK que no exponga headers C puros.

Tabla comparativa exhaustiva

Conclusión

La FFM API en JDK 25 no es una mejora cosmética: es la culminación de un proyecto de rediseño arquitectónico que lleva años en gestación. Para los arquitectos de software Java, el mensaje es directo:

Si estás diseñando nuevas integraciones nativas, usa FFM sin dudarlo. La eliminación del toolchain dual, la transparencia para el JIT, la gestión determinista de memoria off-heap y las garantías de seguridad espacial/temporal justifican la inversión completamente.

Si tienes código JNI existente y estable, no lo migres por el solo hecho de migrar. Evalúa si el beneficio compensa el riesgo operativo. Pero síejecuta tu CI con --illegal-native-access=deny hoy, para no quedar atrapado cuando JDK anuncie el endurecimiento definitivo.

El único anti-patrón claro de FFM son los upcalls frecuentes (código C que llama a Java en bucles internos). Si tu arquitectura los requiere, rediseña para que C ejecute ciclos completos, o considera mantener JNI para ese caso específico.

La evidencia del ecosistema habla por sí sola: Apache Lucene 10.x usa MemorySegment internamente y planea requerir JDK 25 como mínimo en Lucene 11. Netty discute activamente la transición desde JNI. Las advertencias de JEP 472 ya generan ruido en logs de producción. El mundo Java de alto rendimiento se está moviendo. La pregunta no es si migrar a FFM, sino cuándo y cómo hacerlo de forma ordenada.

✓ RESUMEN EJECUTIVO PARA ARQUITECTOS

FFM API = JNI — glue code C + seguridad de memoria + visibilidad JIT + gestión determinista de ciclo de vida. Para nuevas integraciones y data paths críticos: FFM. Para JNI estable con upcalls frecuentes: mantener y endurecer con JEP 472. Para CI/CD desde hoy: --illegal-native-access=deny.

· · ·

REFERENCIAS

1. JEP 454: Foreign Function & Memory API — openjdk.org/jeps/454
2. JEP 472: Prepare to Restrict the Use of JNI (JDK 24) — openjdk.org/jeps/472
3. JEP 502: Stable Values (Preview, JDK 25) — openjdk.org/jeps/502
4. JEP 519: Compact Object Headers (JDK 25) — openjdk.org/jeps/519
5. JEP 521: Generational Shenandoah (JDK 25) — openjdk.org/jeps/521
6. Oracle — JDK 25 GA announcement: oracle.com
7. Oracle — Java SE 25 Core Libraries: FFM API Guide — docs.oracle.com/en/java/javase/25/core/
8. Oracle — java.lang.foreign (Java SE 25) — docs.oracle.com
9. Oracle — StableValue Javadoc (Java SE 25, Preview) — docs.oracle.com/StableValue
10. Oracle — Restricted Methods (JDK 25) — docs.oracle.com/restricted-list
11. Inside.java — Performance Improvements in JDK 25 — inside.java
12. Inside.java — FFM vs. Unsafe. Safety (Sometimes) Has a Cost — inside.java
13. Inside.java — Just Be Lazy (Stable Values deep-dive) — inside.java
14. Inside.java — From JDK 21 to JDK 25: Java Performance Update 2025 — inside.java
15. OWASP — Unsafe JNI (CWE-111) — owasp.org
16. Apache Lucene — Migration Guide (9.0+: NativeUnixDirectory → DirectIODirectory) — lucene.apache.org/MIGRATE
17. Apache Lucene — GitHub Issue #14229: Bump Lucene 11 min Java to 25 — github.com/apache/lucene
18. Netty 4.2 Migration Guide — netty.io
19. Project jextract — jdk.java.net/jextract
20. GraalVM — FFM API in Native Image — docs.oracle.com/en/graalvm/jdk/25/
21. bazlur.ca — When Does Java’s Foreign Function & Memory API Actually Make Sense? (2025)
22. dfa1/rocksdbffm: RocksDB FFM bindings benchmark — github.com/dfa1/rocksdbffm
23. JDK-8345687: Improve the implementation of SegmentFactories::allocateSegment — github.com/openjdk/jdk/pull/22610
24. JDK-8331672: Implement JEP 472 (jnativescan tool) — bugs.openjdk.org
25. InfoQ — JEP 472: Prepare to Restrict the Use of JNI in JDK 24 — infoq.com
26. InfoQ — Java 25 Introduces Stable Values API — infoq.com
27. Hanno Embregts — Java 26 Is Here (Stable Values → ComputedConstant rename) — hanno.codes
28. OpenJDK — JDK 25 Feature List — openjdk.org/projects/jdk/25/