Skip to content
Tech AI Wire

Babashka 1.13.220 añade FFI para llamar a bibliotecas nativas

Babashka 1.13.220 añade una FFI construida sobre la API Panama de Java: un script Clojure ya puede llamar a una biblioteca nativa sin escribir un pod ni nada de Java.

Por Tech AI Wire Team

3 min de lectura

XLinkedIn
A terminal running Babashka 1.13.220, where an ffi-demo.clj script loads zlib through the new foreign function interface and prints version 1.3.1.

Babashka, el entorno de scripting de Clojure de arranque rápido, ya puede llamar directamente a bibliotecas nativas en C. La versión 1.13.220 salió el 31 de agosto de 2026 con una interfaz de funciones foráneas, y su autor, Michiel Borkent, explicó el diseño en su blog. Hasta ahora, llegar a código nativo desde un script de Babashka obligaba a escribir un pod: un programa aparte con el que Babashka habla por un socket. La nueva FFI elimina ese paso.

Una interfaz de funciones foráneas es la fontanería que permite a un lenguaje llamar a otro. Aquí, Clojure llama a C.

Qué hace la nueva interfaz

La implementación se apoya en java.lang.foreign, la Foreign Function and Memory API que llegó al JDK a través del proyecto Panama. Borkent señala que la biblioteca existente coffi se apoya en la misma base. No es, por tanto, un mecanismo a medida, sino la vía oficial de la JVM hacia el código nativo, abierta a los scripts.

La versión cubre más que simples llamadas a funciones. Según las notas de la versión en GitHub, el trabajo abarca las pull requests #2031 a #2077 e incluye segmentos de memoria, gestión de arenas, disposiciones de structs y uniones, y callbacks. Los callbacks importan: permiten que una biblioteca C llame de vuelta a tu código Clojure.

La memoria es la parte que exige atención. La memoria nativa queda fuera del recolector de basura, así que Babashka obliga a gestionarla de forma explícita mediante arenas. Una arena posee un bloque de memoria nativa y lo libera al cerrarse. El with-open de Clojure hace esa limpieza automáticamente al final del bloque. Si te equivocas, no recibes una excepción. Recibes un segfault.

Una primera llamada es pequeña. Cargar zlib y pedirle su versión devuelve la cadena 1.3.1.

Por qué importa el ejemplo de SQLite

El ejemplo que destaca Borkent no es un juguete. La FFI permite definir una función Clojure y registrarla dentro de una base de datos nativa, de modo que una consulta SQLite la llame durante su ejecución.

Con pods no era posible. Un pod corre en su propio proceso, y SQLite no puede cruzar un socket en mitad de la evaluación de una consulta. La función tiene que vivir en el mismo proceso que el motor de la base de datos. La FFI directa la coloca ahí.

Esa es la forma general del cambio. Todo lo que exigía que tu código y la biblioteca nativa compartieran un proceso y un espacio de memoria quedaba fuera de alcance. Callbacks, asignadores propios y puntos de extensión dentro del proceso quedan ahora abiertos.

Un cambio más silencioso en los binarios de Linux

Una línea de la versión afecta a quien nunca toque la FFI. En Linux, la compilación por defecto de Babashka pasa de totalmente estática a mayormente estática, lo que significa que glibc ahora se enlaza de forma dinámica. Las compilaciones de macOS y Windows ya funcionaban así.

El motivo es la propia FFI: cargar bibliotecas nativas arbitrarias en tiempo de ejecución encaja mal con un binario totalmente estático. El precio es la portabilidad. Un binario totalmente estático corre en cualquier sitio; uno mayormente estático espera una glibc compatible en el host. Si copias Babashka a un contenedor mínimo o a una imagen Alpine, pruébalo antes de actualizar.

Qué significa esto para los desarrolladores

Si ya usas Babashka para scripts y has evitado una tarea porque necesitaba una biblioteca C, vuelve a mirarla. El rodeo por los pods era fricción real y ha desaparecido.

Si mantienes un pod, conviene leer esto con calma. Los pods siguen teniendo sentido para aislar y para envolver SDK nativos grandes. Ya no lo tienen solo para alcanzar un puñado de funciones C.

Si empiezas ahora, arranca por las reglas de las arenas antes que por la sintaxis de llamada. Llamar a zlibVersion es fácil. Saber qué memoria posees, y cuándo se libera, es lo que separa un script que funciona de un fallo intermitente. Envuelve cada arena en with-open mientras no tengas un motivo para no hacerlo.

Y si despliegas Babashka en contenedores, revisa la glibc de tu imagen base antes de pasar a 1.13.220. Ese cambio llega uses o no la nueva interfaz.

Fuentes

  1. Babashka FFI - Michiel Borkent
  2. Babashka releases: v1.13.220 - GitHub

Artículos relacionados

A process listing on a Kubernetes v1.37 node, showing containerd, kubelet and kube-proxy owned by the kube user while the systemd services still run as root.
Dev Stack

Kubernetes 1.37 pasa el modo rootless a beta

Kubernetes 1.37 pasa KubeletInUserNamespace a beta. El kubelet, los runtimes de contenedores, los plugins CNI y kube-proxy ya pueden ejecutarse como usuario corriente.