Bases de Datos Vectoriales: la memoria de las aplicaciones de IA

Cuando hablamos de Inteligencia Artificial y modelos de lenguaje (LLMs), solemos pensar en el modelo en sí. Sin embargo, gran parte de las aplicaciones modernas de IA dependen de otro componente fundamental: las bases de datos vectoriales.

¿Por qué son necesarias?

Los LLMs poseen conocimiento general, pero no conocen nuestros documentos, manuales, correos o información específica de una empresa.

Si queremos construir un chatbot que responda preguntas sobre nuestra propia información, necesitamos una forma eficiente de almacenar y buscar ese conocimiento.

Aquí es donde entran las bases de datos vectoriales.

¿Qué es un vector?

Un vector es una representación numérica de un texto, una imagen o cualquier otro dato.

Por ejemplo:

"Java es un lenguaje orientado a objetos"

↓

[0.24, -0.81, 0.53, 0.17, ...]

Este proceso se realiza mediante un modelo de embeddings.

La idea es que textos con significados similares tendrán vectores cercanos entre sí.

Por ejemplo:

"¿Cómo crear una API REST con Spring?"

"Tutorial de Spring Boot para servicios REST"

Sus vectores estarán próximos en el espacio vectorial, aunque las frases sean distintas.

¿Cómo funciona una búsqueda vectorial?

Supongamos que almacenamos miles de documentos.

Cuando el usuario realiza una pregunta:

¿Cómo conectarse a una base de datos con Spring Boot?

1. La pregunta se convierte en un vector.

2. Se buscan los vectores más cercanos.

3. Se recuperan los documentos más relevantes.

4. Esa información se envía al LLM.

5. El modelo genera una respuesta basada en esos documentos.

Este patrón se conoce como RAG (Retrieval-Augmented Generation).

Usuario

   ↓

Pregunta

   ↓

Embedding

   ↓

Base de datos vectorial

   ↓

Documentos relevantes

   ↓

LLM

   ↓

Respuesta

¿Cómo se mide la similitud?

Las bases de datos vectoriales utilizan diferentes métricas:

Similitud del coseno

Mide qué tan parecidos son dos vectores según el ángulo entre ellos.

Coseno = 1

→ Muy similares

Coseno = 0

→ Sin relación

Coseno = -1

→ Opuestos

Es una de las métricas más utilizadas en NLP.

Distancia Euclidiana

Mide la distancia entre dos puntos.

Menor distancia

→ Mayor similitud

Producto escalar (Dot Product)

Evalúa la relación entre vectores considerando tanto dirección como magnitud.

¿Por qué no usar una base de datos relacional?

En una base de datos tradicional podríamos hacer:

SELECT *

FROM documentos

WHERE contenido LIKE '%Spring%'

Pero esto presenta limitaciones:

• Solo encuentra coincidencias literales.
• No comprende el significado.
• No detecta sinónimos.
• Escala mal con millones de embeddings.

Una búsqueda vectorial permite consultas semánticas:

Pregunta:

¿Cómo consumir una API REST?

Documento encontrado:

Guía para invocar servicios web HTTP con Spring.

Aunque las palabras sean distintas, el significado es similar.

Comparar un vector con millones de otros puede ser costoso.

Por ello, las bases de datos vectoriales utilizan algoritmos como:

• HNSW (Hierarchical Navigable Small World)
• IVF (Inverted File Index)
• PQ (Product Quantization)

Estos algoritmos permiten encontrar los vecinos más cercanos de manera eficiente sin tener que recorrer todos los vectores.

Bases de datos vectoriales populares

Pinecone

Servicio administrado diseñado específicamente para IA.

Características:

• Escalabilidad automática.
• API sencilla.
• Alta disponibilidad.

Milvus

Proyecto open source muy popular.

Características:

• Alto rendimiento.
• Soporte para miles de millones de vectores.
• Compatible con GPU.

Qdrant

Base de datos open source escrita en Rust.

Características:

• Excelente rendimiento.
• Filtros avanzados.
• API REST y gRPC.

Weaviate

Incluye capacidades de búsqueda híbrida y soporte para GraphQL.

Chroma

Muy utilizada en proyectos pequeños y prototipos.

PostgreSQL + pgvector

Permite agregar capacidades vectoriales a PostgreSQL.

Ideal cuando ya se utiliza PostgreSQL y no se necesita una solución especializada.

¿Siempre necesito una base de datos vectorial?

No necesariamente.

Para muchos proyectos pequeños, PostgreSQL con la extensión pgvector puede ser suficiente.

Una base vectorial especializada comienza a mostrar ventajas cuando:

• Existen millones de embeddings.
• Se requieren búsquedas muy rápidas.
• Hay múltiples usuarios concurrentes.
• Se necesita alta escalabilidad.

Las bases de datos vectoriales se han convertido en uno de los componentes fundamentales de las aplicaciones modernas de IA.

Su objetivo no es reemplazar a las bases de datos tradicionales, sino complementar a los LLMs proporcionando una forma eficiente de almacenar y recuperar información basada en significado y no únicamente en palabras exactas.

En otras palabras, si los LLMs son el cerebro de una aplicación de IA, las bases de datos vectoriales actúan como su memoria externa, permitiendo implementar asistentes, chatbots y sistemas RAG capaces de trabajar con conocimiento actualizado y específico.

ANTLR: El primer paso para construir un lenguaje de programación

Cuando usamos Java, Kotlin o Scala, normalmente escribimos código sin pensar demasiado en lo que ocurre detrás de escena.

int result = 10 + 20;

Sin embargo, antes de que la JVM pueda ejecutar ese programa, alguien tuvo que diseñar un compilador capaz de entender ese texto y transformarlo en bytecode.

En esta serie vamos a construir nuestro propio lenguaje para la JVM. No pretendemos competir con Kotlin o Scala, pero sí recorrer muchos de los mismos conceptos que utilizan estos lenguajes internamente.

Y el primer paso es aprender una herramienta fundamental: ANTLR.

¿Qué es ANTLR?

ANTLR (ANother Tool for Language Recognition) es una herramienta que permite generar analizadores léxicos y sintácticos a partir de una gramática.

En lugar de escribir manualmente todo el código necesario para interpretar un lenguaje, simplemente describimos las reglas del mismo y ANTLR genera automáticamente gran parte de la infraestructura necesaria.

Por ejemplo, podemos definir una regla como:

expression

    : expression '+' expression

    | NUMBER

    ;

A partir de ella ANTLR podrá reconocer expresiones como:

1 + 2 + 3

Un compilador suele dividirse en varias etapas:

Código Fuente

      │

      ▼

 Lexer

      │

      ▼

 Tokens

      │

      ▼

 Parser

      │

      ▼

 AST

      │

      ▼

 Análisis Semántico

      │

      ▼

 Generación de Código

ANTLR participa principalmente en las dos primeras:

• Lexer
• Parser

¿Qué hace el Lexer?

El Lexer toma una secuencia de caracteres y la divide en tokens.

Por ejemplo:

let age = 42

se transforma en:

LET

IDENTIFIER(age)

ASSIGN

NUMBER(42)

El Lexer no entiende el significado del programa. Solo identifica patrones.

¿Qué hace el Parser?

El Parser toma los tokens generados por el Lexer y verifica que respeten las reglas definidas por la gramática.

Por ejemplo:

LET IDENTIFIER ASSIGN NUMBER

podría convertirse en:

Assignment

 ├── Variable(age)

 └── Number(42)

Esta estructura representa la forma del programa y servirá como base para las siguientes etapas.

¿Qué es una gramática?

Una gramática define qué construcciones son válidas dentro de un lenguaje.

Por ejemplo:

variableDeclaration

    : 'let' IDENTIFIER '=' expression

    ;

Esta regla indica que una declaración válida debe contener:

• La palabra reservada let
• Un identificador
• El símbolo =
• Una expresión

¿ANTLR genera compiladores?

No.

ANTLR resuelve principalmente:

• Análisis léxico
• Parsing

Todavía debemos implementar:

• Árboles sintácticos abstractos (AST)
• Tablas de símbolos
• Sistema de tipos
• Generación de bytecode JVM

Por eso ANTLR es una herramienta muy importante, pero representa solo una parte del compilador completo.

Java 26: LazyConstant

Una de las novedades de Java 26 es LazyConstant, una API experimental que permite definir constantes inicializadas bajo demanda (*lazy initialization*) de forma segura y eficiente.

Supongamos que tenemos un objeto costoso de crear:

public class Config {

    private static final ExpensiveObject INSTANCE =

            new ExpensiveObject();

}

El objeto se crea cuando la clase es cargada, aunque nunca llegue a utilizarse.

Una solución clásica es utilizar el patrón Initialization-on-demand holder:

public class Config {

    private static class Holder {

        static final ExpensiveObject INSTANCE =

                new ExpensiveObject();

    }

    public static ExpensiveObject instance() {

        return Holder.INSTANCE;

    }

}

Funciona, pero es un patrón poco evidente y algo verboso.

Con Java 26 podemos declarar un valor que será calculado únicamente la primera vez que se necesite:

private static final LazyConstant<ExpensiveObject> INSTANCE =

        LazyConstant.of(ExpensiveObject::new);

y obtenerlo mediante:

ExpensiveObject obj = INSTANCE.get();

La instancia se crea una sola vez y es segura para múltiples hilos.

Veamos un ejemplo:

class DatabaseConnection {

    private static final LazyConstant<ConnectionPool> POOL =

            LazyConstant.of(ConnectionPool::new);

    static ConnectionPool pool() {

        return POOL.get();

    }

}

La conexión se abrirá únicamente cuando alguien invoque:

DatabaseConnection.pool();

¿Qué ventajas tiene?

• Inicialización diferida (lazy initialization).
• Thread-safe.
• Evita implementar patrones complejos.
• Más legible que usar synchronized, volatile o double-checked locking.
• Puede reemplazar muchos usos de AtomicReference.

LazyConstant está pensado para recursos costosos o poco utilizados, donde tiene sentido retrasar su creación.

Durante años, Java obligó a utilizar patrones como el Holder idiom o double-checked locking para conseguir inicialización perezosa segura. Java 26 introduce LazyConstant para convertir ese patrón en una característica del lenguaje y la biblioteca estándar, haciendo el código más simple, legible y menos propenso a errores.

¿Por qué Clojure compila diferente? Ventajas y desventajas de ser un "Hosted Language" en la JVM

Cuando pensamos en lenguajes para la JVM, solemos meter en la misma bolsa a Java, Scala, Kotlin y Clojure. Después de todo, todos terminan ejecutándose sobre la misma máquina virtual.

Pero hay una diferencia fundamental en cómo están construidos.

Scala y Kotlin generan bytecode JVM de manera bastante directa. Clojure, en cambio, adopta una filosofía distinta: es un hosted language, es decir, un lenguaje "hospedado" sobre la plataforma Java.

¿Y qué significa eso? ¿Tiene ventajas? ¿Tiene costos?

Lenguajes como Java, Scala o Kotlin siguen aproximadamente este esquema:

Código fuente

      ↓

Compilador

      ↓

Bytecode JVM (.class)

      ↓

JVM

Muchas características del lenguaje se traducen directamente en clases, métodos y bytecode especializado.

Por ejemplo, una case class de Scala:

case class Person(name: String)

genera automáticamente métodos como:

• equals()
• hashCode()
• copy()
• toString()

Todo esto queda representado directamente en bytecode.

Clojure también produce bytecode JVM, pero gran parte del comportamiento del lenguaje vive en su runtime:

Código Clojure

      ↓

Compilador

      ↓

Bytecode + Runtime de Clojure

      ↓

JVM

Por eso Rich Hickey describe a Clojure como un hosted language.

La plataforma Java no es solamente un destino de compilación: es el ecosistema sobre el cual está construido el lenguaje.

Ventaja: Aprovecha toda la plataforma Java

Desde Clojure podemos usar directamente cualquier clase Java:

(import java.time.LocalDate)

(LocalDate/now)

No hay puentes especiales ni adaptadores.

Clojure reutiliza:

• la JVM;
• el recolector de basura;
• las bibliotecas Java;
• los hilos;
• las excepciones;
• las herramientas de profiling;
• todo el ecosistema existente.

En vez de reinventar la rueda, se apoya en ella.

Ventaja: Un compilador relativamente pequeño

Muchas características importantes de Clojure viven en bibliotecas y no en el compilador:

• secuencias perezosas;
• colecciones persistentes;
• STM;
• transducers.

Esto hace que el compilador sea considerablemente más sencillo que los de Scala o Kotlin.

Ventaja: Desarrollo interactivo y REPL

Una de las mayores fortalezas de Clojure es su modelo de desarrollo interactivo.

Podemos definir una función:

(defn cuadrado [x]

  (* x x))

y cargarla inmediatamente en la REPL, sin recompilar todo el proyecto.

Este enfoque favorece:

• feedback rápido;
• hot reloading;
• experimentación;
• desarrollo incremental.

Ventaja: Evolución mediante librerías

Muchas características avanzadas de Clojure se agregaron sin modificar demasiado el lenguaje:

• transducers;
• core.async;
• spec;
• STM.

Al depender más del runtime y menos del compilador, la evolución del ecosistema suele ser más flexible.

Las desventajas

Menos optimizaciones

Scala y Kotlin generan bytecode más especializado.

En Clojure, muchas operaciones pasan por componentes del runtime como:

• IFn;
• PersistentVector;
• PersistentMap;
• RT.

Esto introduce niveles adicionales de indirección y, en ciertos casos, puede afectar el rendimiento.

Más reflexión

Si escribimos:

(defn largo [s]

  (.length s))

el compilador puede recurrir a reflexión.

Podemos ayudarlo con type hints:

(defn largo [^String s]

  (.length s))

pero esto requiere intervención del programador.

Menos comprobaciones en tiempo de compilación

Scala y Kotlin verifican muchas cosas antes de ejecutar:

• tipos;
• nulabilidad;
• exhaustividad del pattern matching;
• restricciones genéricas.

Clojure, al ser dinámico, detecta muchos errores recién en tiempo de ejecución.

Interoperabilidad asimétrica

Desde Clojure usar Java es muy fácil.

Pero desde Java consumir código Clojure no es tan natural:

IFn plus = Clojure.var("myns", "plus");

Mientras que una clase escrita en Scala o Kotlin suele verse como una clase Java convencional.

Dos filosofías distintas

No es que una aproximación sea mejor que la otra.

Scala y Kotlin intentan enriquecer la JVM mediante compiladores sofisticados y bytecode especializado.

Clojure adopta otra filosofía: construir un lenguaje pequeño y dinámico que reutilice al máximo la plataforma existente.

Al final, la diferencia más interesante no es a qué compilan, porque todos terminan ejecutándose en la JVM.

La verdadera diferencia es: ¿Cuánto del lenguaje vive en el compilador y cuánto vive en el runtime?

Y en esa decisión de diseño está gran parte de la personalidad de Clojure.

 

¿Cuáles son las tendencias en la infraestructura de IA? Cómo 1,300 líderes de TI están diseñando la arquitectura para la IA. Acceder al informe

Hola Emanuel,

Es difícil mantenerse al día con las últimas tendencias en infraestructura cuando la tecnología cambia casi a diario. Para que llegues directo al grano, nos asociamos con IDC para encuestar a 1,300 líderes de TI globales y descubrir cómo están diseñando su infraestructura.En este documento, encontrarás lo siguiente:

Datos comparativos sobre la distribución de cargas de trabajo, la medición, el marco de trabajo y la selección de proveedores Los principales cuellos de botella, tanto técnicos como operativos, que dificultan la eficiencia de la IA en la actualidad Prioridades de inversión futuras que dan forma a los próximos 1 o 2 años de adopción de la IA

Usa esta información para optimizar tus inversiones en IA y mantener a tu organización a la vanguardia.

Nos vemos en la nube, El equipo de Google Cloud

© 2026 Google LLC 1600 Amphitheatre Parkway, Mountain View, CA 94043

JDBI en Java: acceso a datos simple

Cuando hablamos de acceso a bases de datos en Java, solemos pensar en JDBC puro o en frameworks pesados como Hibernate.

Pero existe una opción intermedia muy interesante: Jdbi.

JDBI busca mantener la simplicidad y el control de SQL, pero eliminando gran parte del código repetitivo de JDBC.

¿Qué es JDBI?

JDBI es una librería que se construye sobre JDBC y agrega:

• Mapeo automático de objetos
• Queries más limpias
• Manejo simplificado de parámetros
• Integración con transacciones
• APIs modernas y funcionales

La idea es poder escribir SQL real sin tener que pelear con ResultSet, PreparedStatement y toneladas de try/catch.

Dependencia Maven:

<dependency>

    <groupId>org.jdbi</groupId>

    <artifactId>jdbi3-core</artifactId>

    <version>3.49.6</version>

</dependency>

Si usamos una base de datos específica, agregamos el driver correspondiente.

Por ejemplo para MySQL:

<dependency>

    <groupId>com.mysql</groupId>

    <artifactId>mysql-connector-j</artifactId>

</dependency>

Crear una conexión:

Jdbi jdbi = Jdbi.create(

    "jdbc:mysql://localhost:3306/test",

    "root",

    "password"

);

Ejecutar una consulta

Supongamos esta tabla:

CREATE TABLE users (

    id BIGINT PRIMARY KEY,

    name VARCHAR(100),

    age INT

);

Y esta clase:

public class User {

    private Long id;

    private String name;

    private Integer age;

    // getters y setters

}

Ahora podemos consultar así:

List<User> users = jdbi.withHandle(handle ->

    handle.createQuery("SELECT * FROM users")

          .mapToBean(User.class)

          .list()

);

Fijate que desaparece todo el manejo manual de ResultSet.

Insertar datos:

jdbi.useHandle(handle ->

    handle.createUpdate("""

        INSERT INTO users(id, name, age)

        VALUES(:id, :name, :age)

    """)

    .bind("id", 1L)

    .bind("name", "Emanuel")

    .bind("age", 30)

    .execute()

);

Parámetros nombrados

Una de las mejores cosas de JDBI es evitar los clásicos:

statement.setString(1, ...);

statement.setInt(2, ...);

En su lugar:

.bind("name", "Juan")

Mucho más legible.

JDBI también permite definir interfaces tipo DAO.

public interface UserDao {

    @SqlQuery("SELECT * FROM users WHERE id = :id")

    User findById(@Bind("id") Long id);

    @SqlUpdate("""

        INSERT INTO users(id, name, age)

        VALUES(:id, :name, :age)

    """)

    void insert(

        @Bind("id") Long id,

        @Bind("name") String name,

        @Bind("age") Integer age

    );

}

Y luego:

UserDao dao = jdbi.onDemand(UserDao.class);

User user = dao.findById(1L);

¿Por qué mucha gente lo elige?

Porque queda en un punto muy cómodo. No es tan automático como JPA y permite hacer optimizaciones fácilmente, pero no es tan trabajoso como JDBC. 

JDBI se integra muy bien con Spring Framework.

Dependencia:

<dependency>

    <groupId>org.jdbi</groupId>

    <artifactId>jdbi3-spring5</artifactId>

    <version>3.49.6</version>

</dependency>

Configuración:

@Configuration

public class JdbiConfig {

    @Bean

    public Jdbi jdbi(DataSource dataSource) {

        Jdbi jdbi = Jdbi.create(dataSource);

        jdbi.installPlugin(new SqlObjectPlugin());

        return jdbi;

    }

}

Crear el DAO como Bean

@Configuration

public class DaoConfig {

    @Bean

    public UserDao userDao(Jdbi jdbi) {

        return jdbi.onDemand(UserDao.class);

    }

}

Usarlo desde un Service

@Service

public class UserService {

    private final UserDao userDao;

    public UserService(UserDao userDao) {

        this.userDao = userDao;

    }

    public User getUser(Long id) {

        return userDao.findById(id);

    }

}

¿Cuándo conviene usar JDBI?

JDBI suele ser una muy buena opción cuando:

• querés escribir SQL manualmente
• necesitás buena performance
• no querés la complejidad de Hibernate
• trabajás con consultas complejas
• querés algo más moderno que JDBC puro

Especialmente en microservicios o aplicaciones donde el modelo relacional es importante, JDBI puede resultar mucho más simple y transparente que un ORM completo.

Dejo link: https://jdbi.org

Mundial de Lenguajes de Programación

Le pregunte a la IA que onda si hacemos partidos de diferentes tecnologías con diferentes lenguajes, y este fue el resultado : 

Partido 1: Aplicaciones Web

Java vs C#

🇯🇵 Java sale con Spring Boot.

🇺🇸 C# responde con ASP.NET Core.

Ambos tienen experiencia internacional, planteles maduros y una enorme cantidad de títulos.

Resultado: Empate 1-1.

> Si tenés que hacer una API corporativa, cualquiera de los dos te lleva a octavos.

 🏟️ Partido 2: Concurrencia

Elixir vs Go

🇧🇷 Elixir apuesta por la posesión y el juego asociado con actores y supervisores.

🇩🇪 Go juega más directo con goroutines y channels.

Elixir domina el mediocampo cuando aparecen millones de procesos concurrentes.

Resultado: Elixir 2 - Go 1.

La BEAM sigue siendo una de las ligas más difíciles de enfrentar.

 🏟️ Partido 3: Aplicaciones Standalone

C++ vs Rust

🇮🇹 C++ es el veterano con ocho mundiales encima.

🇳🇱 Rust llega con una generación joven y una defensa impecable.

Rust reduce errores, pero C++ todavía tiene una experiencia enorme.

Resultado: C++ 1 - Rust 1.

La leyenda sigue vigente, pero la promesa pide pista.

 🏟️ Partido 4: Cloud

Java vs Node.js

🇦🇷 Java viene con GraalVM y Spring Boot.

🇪🇸 Node.js juega rápido y con poco peso.

En microservicios y aplicaciones cloud modernas, ambos se sienten cómodos.

Resultado: Empate.

El VAR determina que la elección depende más del equipo que del lenguaje.

🏟️ Partido 5: Inteligencia Artificial

Python vs el resto del mundo

🇫🇷 Python entra a la cancha.

Resultado: Python 5 - 0.

Hubo partido durante cinco minutos.

 🏟️ Partido 6: Programación Funcional

Scala vs Haskell

🇺🇾 Scala combina técnica y pragmatismo.

🇭🇷 Haskell juega un fútbol hermoso que pocos entienden.

Resultado: Scala 2 - Haskell 1.

La posesión fue 90% para Haskell, pero Scala convirtió las que tuvo.

🏟️ Partido 7: Frontend

TypeScript vs JavaScript

🇵🇹 JavaScript es el capitán histórico.

🇵🇹 TypeScript es el mismo equipo, pero con preparador físico.

Resultado: TypeScript 3 - JavaScript 1.

 Los errores en tiempo de compilación fueron la figura del partido.

 🏟️ Partido 8: Bases de Datos

PostgreSQL vs MySQL

🇨🇴 PostgreSQL juega con mucha técnica.

🇲🇽 MySQL apuesta por la experiencia.

Resultado: PostgreSQL 2 - MySQL 1.

PostgreSQL ganó por posesión y calidad de juego.

Y listo, no hice mucho, ni dice mucho pero es divertido :P 

FFM API en Java: Accediendo a Memoria Nativa y Código Nativo sin JNI parte 2

 

Seguimos viendo FFM API

Dónde podemos usar FFM API:

Librerías de machine learning

Integración con:

• CUDA,
• TensorRT,
• ONNX Runtime.

Motores gráficos

Bindings contra:

• Vulkan,
• OpenGL,
• SDL.

Bases de datos

Drivers nativos de:

• SQLite,
• RocksDB.

Sistemas embebidos

• Acceso a APIs del sistema operativo.
• Upcalls: cuando C llama a Java

La FFM API también soporta: upcalls

Es decir:

• código nativo llamando código Java.
• Algo parecido a callbacks.

Veamos un ejemplo práctico: strlen

import java.lang.foreign.*;

import java.lang.invoke.MethodHandle;

import static java.lang.foreign.ValueLayout.*;

public class Main {

    public static void main(String[] args) throws Throwable {

         Linker linker = Linker.nativeLinker();

         MemorySegment strlenAddr =

                linker.defaultLookup()

                        .find("strlen")

                        .orElseThrow();

        MethodHandle strlen = linker.downcallHandle(

                strlenAddr,

                FunctionDescriptor.of(JAVA_LONG, ADDRESS)

        );

        try (Arena arena = Arena.ofConfined()) {

            MemorySegment text =

                    arena.allocateFrom("Hola Mundo");

            long size = (long) strlen.invoke(text);

            System.out.println(size);

        }

    }

}

FFM API esta disponible desde Java 21

La FFM API es probablemente uno de los cambios más importantes del ecosistema Java moderno.

Porque permite:

• interoperabilidad nativa,
• manejo eficiente de memoria,
• reemplazar gran parte de JNI,
• acceso a APIs del sistema,
• y programación de bajo nivel.

Todo usando una API moderna y mucho más amigable.

Project Panama abre la puerta a una nueva generación de aplicaciones Java capaces de integrarse con el mundo nativo sin el dolor histórico de JNI.

FFM API en Java: Accediendo a Memoria Nativa y Código Nativo sin JNI

La FFM API (Foreign Function & Memory API) es una de las incorporaciones más interesantes de Java moderno.

Su objetivo es permitir que una aplicación Java pueda:

• Llamar funciones escritas en C.
• Acceder a memoria fuera del heap de la JVM.
• Reemplazar gran parte del uso de JNI.
• Interactuar con librerías nativas de forma más segura y eficiente.

La FFM API forma parte del proyecto Project Panama.

Pero demos un paso para atras,  ¿Por qué existía JNI?

Durante años, si una aplicación Java necesitaba:

• acceder a una librería en C,
• usar código del sistema operativo,
• trabajar con drivers,
• o ejecutar operaciones de bajo nivel,

la única opción era usar JNI (Java Native Interface)

El problema es que JNI:

• es complejo,
• verboso,
• inseguro,
• difícil de debuggear,
• y propenso a crashes de la JVM.

Además, obliga a escribir:

• código Java,
• código C,
• headers,
• compilación nativa,
• glue code.

Puff si no habre puteado con JNI.

¿Qué propone la FFM API?

La FFM API permite hacer esto:

printf("Hola desde C!\n");

...directamente desde Java.

Y además:

• manejar memoria nativa,
• mapear estructuras,
• trabajar con punteros,
• invocar funciones dinámicamente.

Todo usando una API moderna.

La FFM API tiene dos pilares:

1. Foreign Function

Permite invocar funciones nativas.

Por ejemplo:

• printf
• strlen
• malloc
• funciones de librerías C

2. Foreign Memory

Permite manejar memoria fuera del heap de Java.

Esto es importante porque:

• la JVM normalmente controla toda la memoria,
• pero muchas librerías nativas usan memoria propia.

La FFM API permite trabajar con esa memoria de manera segura.

Primer ejemplo: llamar a printf

import java.lang.foreign.*;

import java.lang.invoke.MethodHandle;

import static java.lang.foreign.ValueLayout.*;

public class Main {

    public static void main(String[] args) throws Throwable {

        Linker linker = Linker.nativeLinker();

        SymbolLookup stdlib = linker.defaultLookup();

        MemorySegment printfAddress =

                stdlib.find("printf")

                      .orElseThrow();

        FunctionDescriptor printfSignature =

                FunctionDescriptor.of(JAVA_INT, ADDRESS);

        MethodHandle printf = linker.downcallHandle(

                printfAddress,

                printfSignature

        );

        try (Arena arena = Arena.ofConfined()) {

            MemorySegment text =

                    arena.allocateFrom("Hola desde C!\n");

            printf.invoke(text);

        }

    }

}

¿Qué está pasando acá?

Linker linker = Linker.nativeLinker();

Obtiene un linker capaz de interactuar con funciones nativas.

SymbolLookup stdlib = linker.defaultLookup();

Busca símbolos exportados por librerías nativas.

stdlib.find("printf")

Obtiene la dirección de memoria de la función.

Muy parecido a: void* ptr = dlsym(...)

FunctionDescriptor.of(JAVA_INT, ADDRESS)

Describe la firma de la función.

En este caso: int printf(char*)

linker.downcallHandle(...)

Crea un MethodHandle que permite invocar la función nativa.

Manejo de memoria con Arena

Uno de los conceptos más importantes es:

Un Arena administra memoria nativa.

try (Arena arena = Arena.ofConfined()) {

}

Cuando el bloque termina:

• la memoria se libera automáticamente.
• Esto evita muchísimos memory leaks.

La memoria nativa se representa con: MemorySegment

Es básicamente:

• un bloque de memoria,
• con límites,
• seguro,
• y controlado.

Y para reservar memoria hacemos: 

MemorySegment segment = arena.allocate(4);

Por ejemplo escribir y leer un entero: 

segment.set(JAVA_INT, 0, 42);

int value = segment.get(JAVA_INT, 0);

Supongamos esta estructura:

struct Point {

    int x;

    int y;

};

Podemos modelarla en Java.

StructLayout POINT = MemoryLayout.structLayout(

        JAVA_INT.withName("x"),

        JAVA_INT.withName("y")

);

Y para reservar memoria hacemos:

MemorySegment point = arena.allocate(POINT);

Escribir los campos:

point.set(JAVA_INT, 0, 10);

point.set(JAVA_INT, 4, 20);

¿Qué ventajas tiene?

Menos complejidad

No hace falta:

• generar headers,
• compilar JNI,
• usar glue code.

¿Puede FFM API reemplaza completamente JNI?

Todavía no en todos los casos.

Hay escenarios avanzados donde JNI sigue siendo necesario.

Pero para muchísimos casos:

• bindings simples,
• acceso a librerías,
• llamadas nativas,
• estructuras,

la FFM API es mucho mejor.

Native AOT vs GraalVM Native Image

¿Quién compila mejor a código nativo: .NET o Java?

Durante años, tanto Java como .NET estuvieron dominados por el mismo modelo:

• bytecode/intermediate language
• máquinas virtuales
• JIT compilation
• optimizaciones runtime

Ese enfoque funcionó extremadamente bien durante décadas.

Pero el mundo cambió.

Hoy vivimos en un ecosistema dominado por:

• Kubernetes
• microservicios
• containers efímeros
• serverless
• autoscaling
• cold starts

Y en ese contexto, el tiempo de arranque y el consumo de memoria comenzaron a importar muchísimo más.

Por eso aparecieron dos tecnologías muy similares:

GraalVM

Native AOT de .NET

Ambas prometen algo revolucionario: Compilar aplicaciones administradas a binarios nativos standalone

Pero aunque el objetivo es parecido, las filosofías y enfoques son bastante diferentes.

En java tradicionalmente:

Java -> Bytecode -> JVM -> JIT -> Código Máquina

En .NET:

C# -> IL -> CLR -> JIT -> Código Máquina

Ambos mundos dependen fuertemente de:

• compilación dinámica
• reflection
• metadata
• optimizaciones runtime

En java con GraalVM Native Image:

Java -> Bytecode -> análisis estático -> binario nativo

Native AOT:

C# -> IL -> Native AOT toolchain -> binario nativo

En ambos casos:

• desaparece el JIT
• desaparece gran parte del runtime
• mejora muchísimo el startup

El gran objetivo: Cloud Native

Ambas tecnologías existen por el mismo motivo: reducir startup time y consumo de memoria. Y los dos lo hacen muy bien. 

En el tamaño del binario hay diferencias interesantes.

En GraalVM, los binarios suelen ser bastante grandes. Especialmente con frameworks pesados.

Native AOT, también genera binarios relativamente grandes. Aunque frecuentemente más pequeños en aplicaciones simples.

Y los dos sufren por no poder usar reflection.

AOT y GraalVM necesita saber todo el código que será utilizado.

Eso se llama: Closed World Assumption

El compilador asume: “Sé exactamente qué código será ejecutado.”

Pero reflection rompe esa idea.

Frameworks: acá aparece una diferencia importante

Java históricamente fue MUY dinámico

Frameworks como:

• Spring
• Hibernate
• Jakarta EE

usan reflection masivamente.

Eso vuelve más complejo el AOT.

.NET históricamente fue menos dinámico

ASP.NET Core moderno:

• usa menos magia runtime
• menos reflection extrema
• más generación compile-time

Eso hace que Native AOT encaje bastante naturalmente.

Por eso aparecieron frameworks especiales en Java

Para adaptarse a GraalVM nacieron:

• Quarkus
• Micronaut
• Helidon

Todos intentan:

• minimizar reflection
• mover trabajo al compile-time
• ser AOT friendly

Mientras tanto en .NET. ASP.NET Core Minimal APIs ya estaba bastante alineado con esa filosofía.

Por eso Native AOT se siente más “natural” dentro del ecosistema.

Con respecto a Build Time, GraalVM suele sufrir más. La compilación puede tardar muchísimo. Especialmente en aplicaciones grandes.

Porque realiza:

• análisis estático agresivo
• optimizaciones complejas
• tree shaking profundo

Native AOT, también aumenta el tiempo de build.

Pero generalmente menos extremo.

Ambos son excelentes para containers.

Permiten:

• imágenes más pequeñas
• menor consumo
• escalado más rápido
• menor costo cloud

GraalVM parece:  “Java intentando escapar de la JVM clásica”

Porque el ecosistema Java tradicional:

• depende muchísimo del runtime
• reflection
• proxies
• bytecode generation

Native AOT parece: “La evolución natural de .NET moderno”

ASP.NET Core ya venía moviéndose hacia:

• menos magia
• más compile-time
• menos configuración runtime
• minimalismo

¿Entonces quién gana?

Depende completamente del escenario.

GraalVM brilla especialmente si:

• ya vivís en el ecosistema Java
• necesitás Spring/Quarkus/Micronaut
• querés mejorar startup brutalmente

Native AOT brilla especialmente si:

• trabajás con ASP.NET Core
• hacés microservicios
• usás Minimal APIs
• querés DX muy integrada

Lo más interesante: el regreso del compile-time

Durante años, Java y .NET apostaron fuertemente al runtime dinámico.

Ahora ambos ecosistemas están regresando a:

• compile-time analysis
• generación estática
• tree shaking
• optimización anticipada

Curiosamente, acercándose cada vez más a ideas tradicionales de:

• C++
• Rust
• Go

 ¿Se está muriendo el JIT?

No.

El JIT sigue siendo extremadamente poderoso.

Especialmente para:

• aplicaciones grandes
• workloads largos
• optimizaciones runtime avanzadas
• desktop
• sistemas complejos

Pero el cloud moderno cambió las prioridades.

Hoy muchas veces importa más:

• arrancar rápido
• consumir menos memoria
• escalar rápido
• reducir costos cloud

Y ahí AOT tiene muchísimo sentido.

Tanto GraalVM como Native AOT representan uno de los cambios más importantes en la evolución moderna de las plataformas administradas.

Ambos intentan resolver el mismo problema: Cómo llevar runtimes modernos al mundo cloud-native

Y aunque utilizan estrategias similares, sus ecosistemas muestran diferencias profundas:

• Java todavía lucha contra décadas de dinamismo runtime
• .NET parece haber llegado más preparado al mundo AOT

Sin embargo, ambos demuestran algo muy claro:

El futuro del desarrollo moderno probablemente combine JIT y AOT dependiendo del tipo de aplicación y del contexto donde será ejecutada.

Java Streams vs LINQ

A simple vista, Java y C# parecen ofrecer lo mismo:

users.stream()

     .filter(u -> u.getAge() > 50)

     .toList();

users.Where(u => u.Age > 50).ToList();

• Sintaxis similar
• Misma intención

Pero internamente… son dos mundos completamente distintos.

• En Java, una lambda es código ejecutable
• En LINQ, puede ser datos (un AST)

Y eso cambia todo.

En Java, esto:

Predicate<User> p = u -> u.getAge() > 50;

Se compila a bytecode usando invokedynamic

Es equivalente a:

class Lambda implements Predicate<User> {

    public boolean test(User u) {

        return u.getAge() > 50;

    }

}

No hay forma de saber:

• qué propiedad se accede (age)
• qué operador se usa (>)
• qué constante (50)

Solo podés ejecutarla, no analizarla

Por lo tanto, siempre ocurre en memoria. Nunca puede transformarse en sql o en nada

En .NET LINQ, esto:

users.Where(u => u.Age > 50)

Puede ser interpretado como:

Expression<Func<User, bool>>

Esto NO es una función

Es un árbol de expresión (AST)

¿Cómo se ve ese AST?

Conceptualmente:

GreaterThan

 ├── MemberAccess (Age)

 └── Constant (50)

O en código:

BinaryExpression(

    left: MemberExpression("Age"),

    operator: GreaterThan,

    right: Constant(50)

)

Ahora sí podés:

• traducir a SQL
• optimizar
• serializar
• ejecutar en distintos motores

¿Por qué Java eligió este camino?

Java priorizó:

• simplicidad
• performance
• compatibilidad

Las lambdas fueron diseñadas como:  “syntactic sugar” sobre interfaces funcionales

No como estructuras analizables.

 ¿Se podría implementar LINQ en Java?

Sí… pero requeriría:

• lambdas introspectables
• un AST estándar en el lenguaje
• cambios en el compilador

Streams y LINQ no son equivalentes.

• Streams son pipelines de ejecución
• LINQ es un lenguaje de queries embebido

¿Se puede tener Java Linq?

Sí, podría… pero no “gratis” ni sin romper varias cosas del lenguaje como hoy está diseñado.

La clave es entender qué significa realmente “expresión” al estilo LINQ.

Primero: ¿qué es una “expresión” en LINQ?

En .NET LINQ no estás pasando una función común.

x => x.Age > 50

Eso puede ser dos cosas distintas en C#:

Func<User, bool>                 // código ejecutable

Expression<Func<User, bool>>    // árbol de expresión (AST)

En el segundo caso, el compilador no genera bytecode directo, sino una estructura tipo:

GreaterThan

 ├── MemberAccess (Age)

 └── Constant (50)

En Java eso NO existe

x -> x.getAge() > 50

Siempre es: Predicate<User>

Y eso es:

• bytecode
• opaco
• no analizable

Entonces… ¿por qué Java no puede simplemente agregarlo?

Puede… pero implicaría cambios profundos 

1. Cambiar cómo funcionan las lambdas

Hoy en Java:

Predicate<User> p = x -> x.getAge() > 50;

 Se compila usando invokedynamic

Es básicamente una función

Para soportar expresiones, Java necesitaría algo como:

Expression<User, Boolean> expr = x -> x.getAge() > 50;

Eso implica que el compilador:

• capture la estructura del código
• no solo lo ejecute

2. Falta un AST estándar en el lenguaje

Java no tiene algo como:

expr.getBody(); // árbol de nodos

Tendrías que definir:

• nodos (BinaryExpression, MethodCall, etc.)
• un modelo estándar
• APIs para recorrerlo

Básicamente: meter un mini compilador dentro del lenguaje

3. Problema de ambigüedad (esto es clave)

¿Qué pasa con esto?

x -> x.getAge() > calcularEdadMinima()

¿Eso es SQL?

 ❌ No siempre

 ❌ Puede depender de lógica Java

 ❌ Puede tener efectos secundarios

LINQ tiene reglas estrictas para esto… Java no.

4. Compatibilidad hacia atrás (el verdadero monstruo)

Java es ultra conservador.

Si agregás expresiones:

• ¿cómo diferenciás `Predicate` vs `Expression`?
•  ¿rompés código existente?
• ¿cómo inferís tipos?

C# lo resolvió desde el diseño… Java llegó tarde (lambdas en Java 8).

5.  Filosofía del lenguaje

Java prioriza:

• simplicidad
• previsibilidad
• menos “magia”

LINQ introduce:

• traducción implícita
• múltiples targets (SQL, XML, memoria)
• comportamiento distinto según contexto

Eso no encaja del todo con el ADN de Java

Entonces… ¿es imposible?

No. Para nada.

De hecho, Java ya hace algo parecido, pero explícito:

• JPA Criteria API
• Querydsl
• jOOQ

Todos construyen un AST… pero a mano

La posta (la diferencia real)

No es que Java “no pueda”.

Es que hoy:

• Las lambdas en Java son comportamiento
• En LINQ son datos

 Conclusión

Java podría implementar algo tipo LINQ si:

• introduce un tipo `Expression`
• cambia el compilador
• define un AST estándar
• acepta más complejidad en el lenguaje

Pero eso implicaría:

cambiar una de las decisiones fundamentales de cómo Java entiende las lambdas

¿Por qué Java Streams no pueden ser LINQ?

Imaginá esto:

repoPersona

    .filter(p -> p.getEdad() > 50)

    .toList();

Y que mágicamente se transforme en:

SELECT * FROM persona WHERE edad > 50;

Sería hermoso.

Pero… ¿no son lazy los streams?

Sí, los streams en Java son lazy:

users.stream()

     .filter(u -> u.getAge() > 50)

     .toList();

No se ejecuta hasta el final

Peeeero...

Lazy no es lo mismo que interpretable

En Java, esto:

u -> u.getAge() > 50

Se compila a bytecode

No queda como estructura accesible

Es decir:

• No podés analizarla
• No podés transformarla
• No podés convertirla en SQL

 ¿Por qué en C# sí se puede?

En .NET LINQ pasa algo distinto:

repo.Where(x => x.Age > 50)

Eso no es una función normal

Es: Expression<Func<T, bool>>

El código es datos (un AST)

Por esta razón necesitamos de cosas como Specification de jpa para tipar nuestras querys :(

Java Streams no pueden ser LINQ porque:  Java no puede “leer” lambdas como datos

Y eso obliga a usar soluciones como Specifications.

Specifications de JPA: Queries dinámicas y tipadas en Java

Cuando trabajamos con bases de datos en Java usando Spring Data JPA, tarde o temprano aparece un problema:

¿Cómo construyo queries dinámicas sin escribir SQL a mano?

Ahí es donde entra el patrón Specification.

Una Specification<T> es básicamente un predicado tipado que se traduce a SQL.

Permite expresar condiciones de forma declarativa:

Specification<User> isAdult = (root, query, cb) ->

    cb.greaterThanOrEqualTo(root.get("age"), 18);

Esto termina siendo:

WHERE age >= 18

Composición: el verdadero poder. Lo más interesante es que las specifications se pueden combinar:

Specification<User> isAdult = (root, query, cb) ->

    cb.greaterThanOrEqualTo(root.get("age"), 18);

Specification<User> nameStartsWithA = (root, query, cb) ->

    cb.like(root.get("name"), "A%");

Specification<User> combined =

    isAdult.and(nameStartsWithA);

WHERE age >= 18 AND name LIKE 'A%'

Se puede usar en el dao o repositorio así:

List<User> result = userRepository.findAll(combined);

Simple, expresivo y reutilizable.

Ventajas:

• Queries dinámicas
• Composición (`and`, `or`)
• Tipado fuerte
• Evita strings SQL

Desventajas:

• Verboso (Criteria API no es linda)
• Poco intuitivo al principio
• Debug complicado

¿Qué está pasando por debajo?

Todo esto se apoya en JPA Criteria API

• No estás ejecutando código
• Estás construyendo un árbol de expresión (AST)

Por eso puede traducirse a SQL.

Specification es una forma poderosa de:

construir queries dinámicas, reutilizables y tipadas en Java

Pero… deja una pregunta interesante. ¿No podríamos hacer esto mismo con Streams?

Lo veremos en próximos posts ...

Jakarta Persistence 4.0: El mayor salto de JPA en años

Durante mucho tiempo, cuando hablábamos de persistencia en Java, hablábamos de JPA. Con la migración de Java EE a Jakarta EE, JPA pasó a llamarse Jakarta Persistence, pero durante varias versiones los cambios fueron relativamente modestos.

Con Jakarta Persistence 4.0 eso cambia.

Esta nueva versión incorpora características largamente esperadas, mejora la seguridad de tipos y prepara el terreno para trabajar junto a Jakarta Data. Veamos qué trae de nuevo.

¿Qué es Jakarta Persistence?

Jakarta Persistence es la especificación estándar para el mapeo objeto-relacional (ORM) en Java.

Permite representar tablas como objetos Java y realizar operaciones CRUD sin escribir SQL para cada interacción.

@Entity

public class Cliente {

    @Id

    private Long id;

    private String nombre;

}

Implementaciones populares incluyen:

• Hibernate ORM
• EclipseLink

Novedades más importantes de Jakarta Persistence 4.0:

1. EntityAgent: trabajar sin Persistence Context

Una de las novedades más llamativas es la incorporación de EntityAgent.

Hasta ahora, casi todas las operaciones pasaban por un EntityManager y un Persistence Context.

entityManager.persist(cliente);

Con EntityAgent se pueden realizar operaciones sobre entidades desacopladas del contexto de persistencia, simplificando ciertos escenarios y reduciendo overhead. 

Conceptualmente:

entityAgent.insert(cliente);

Esto acerca la API a modelos más ligeros y modernos.

2. Carga masiva por ID

Un problema clásico:

for(Long id : ids) {

    entityManager.find(Cliente.class, id);

}

Esto puede generar el famoso problema N+1.

Jakarta Persistence 4.0 incorpora soporte para obtener múltiples entidades por identificador en una sola operación. 

La ventaja:

• Menos viajes a la base de datos.
• Mejor rendimiento.
• Código más simple.

3. Consultas más seguras con Static Query

Una crítica frecuente a JPA era que las consultas JPQL eran simples Strings.

@Query("select c from Cliente c")

Si el nombre de una propiedad cambiaba, el error aparecía recién en tiempo de ejecución.

Persistence 4.0 incorpora una API de Static Queries que permite mayor verificación en compilación. 

Beneficios:

• Más seguridad de tipos.
• Menos errores en producción.
• Mejor soporte para herramientas y refactorización.

4. Result Set Mapping programático

Hasta ahora era habitual definir mapeos complejos mediante anotaciones.

@SqlResultSetMapping(...)

La nueva versión agrega una API programática para definir estos mappings. 

Ventajas:

• Más flexible.
• Más reutilizable.
• Menos anotaciones gigantes.

5. Nuevas capacidades para Entity Graphs

Los Entity Graphs fueron introducidos para controlar qué relaciones se cargan.

@EntityGraph(attributePaths = {

    "pedidos",

    "direccion"

})

Persistence 4.0 mejora significativamente esta funcionalidad:

Nuevas anotaciones.

Mejor integración con operaciones existentes.

Uso de Entity Graphs en refresh(). 

6. Soporte para entidades Read-Only

En muchos escenarios solo queremos leer datos.

Antes:

Cliente cliente =

    entityManager.find(Cliente.class, id);

La entidad quedaba administrada por el contexto.

Persistence 4.0 agrega soporte explícito para carga en modo solo lectura. 

Beneficios:

• Menor consumo de memoria.
• Menor costo de dirty checking.
• Mejor rendimiento.

7. @PreMerge

Hasta ahora existían callbacks como:

@PrePersist

@PostPersist

@PreUpdate

@PostUpdate

Ahora aparece:

@PreMerge

public void beforeMerge() {

    System.out.println("Fusionando entidad");

}

Esto permite interceptar el proceso de merge antes de que ocurra. 

8. Excluir campos del Optimistic Locking

Hasta ahora cualquier modificación podía afectar el control de versiones.

Persistence 4.0 incorpora una anotación para excluir ciertos atributos del mecanismo de optimistic locking. 

Ideal para:

• Campos calculados.
• Contadores.
• Metadatos auxiliares.

9. select new implícito

Actualmente:

select new ClienteDTO(

    c.id,

    c.nombre

)

from Cliente c

Persistence 4.0 simplifica este escenario permitiendo inferir automáticamente el DTO cuando se especifica el tipo de resultado. 

10. Preparándose para Jakarta Data

Quizás el cambio más importante no sea una característica puntual.

Muchas de las nuevas APIs fueron diseñadas para trabajar mejor con Jakarta Data

La idea es ofrecer una experiencia similar a:

• Spring Data
• Micronaut Data
• Quarkus Panache

pero de forma estandarizada dentro del ecosistema Jakarta EE. 

¿Vale la pena actualizar?

• Si estás usando:
• Hibernate moderno
• Jakarta EE 11 o futuro Jakarta EE 12
• Nuevos proyectos

la respuesta es sí.

Las mejoras apuntan a problemas reales que los desarrolladores vienen sufriendo desde hace años:

• Más type safety
• Menos Strings mágicos
• Mejor rendimiento
• Mejor integración con Jakarta Data
• APIs más modernas

Jakarta Persistence 4.0 representa probablemente la evolución más importante de JPA desde la llegada de los Entity Graphs y los Stored Procedures.

La incorporación de EntityAgent, Static Queries, Result Set Mapping programático, mejoras en Entity Graphs y nuevas capacidades de carga hacen que la especificación se vea mucho más moderna y preparada para competir con las soluciones de persistencia actuales. 

Para quienes pensaban que JPA había quedado estancado, Jakarta Persistence 4.0 demuestra exactamente lo contrario.

Dejo link: 

https://jakarta.ee/specifications/persistence/4.0/