Babashka 1.13.220 ajoute une FFI pour les bibliothèques natives

Babashka, l'environnement de script Clojure au démarrage rapide, peut désormais appeler directement des bibliothèques C natives. La version 1.13.220 est sortie le 31 août 2026 avec une interface de fonctions étrangères, et son auteur Michiel Borkent en a expliqué la conception sur son blog. Jusqu'ici, atteindre du code natif depuis un script Babashka supposait d'écrire un pod : un programme séparé avec lequel Babashka dialogue par socket. La nouvelle FFI supprime cette étape.

Une interface de fonctions étrangères est la plomberie qui permet à un langage d'en appeler un autre. Ici, Clojure appelle C.

Ce que fait la nouvelle interface

L'implémentation repose sur java.lang.foreign, la Foreign Function and Memory API arrivée dans le JDK par le projet Panama. Borkent note que la bibliothèque existante coffi s'appuie sur la même base. Ce n'est donc pas un mécanisme maison, mais la voie officielle de la JVM vers le code natif, ouverte aux scripts.

La version couvre plus que de simples appels de fonctions. D'après les notes de version sur GitHub, le travail s'étend des pull requests #2031 à #2077 et comprend les segments mémoire, la gestion des arènes, les dispositions de structures et d'unions, et les callbacks. Les callbacks comptent : ils permettent à une bibliothèque C de rappeler votre code Clojure.

La mémoire est la partie qui exige de l'attention. La mémoire native se trouve hors du ramasse-miettes, donc Babashka vous oblige à la gérer explicitement via des arènes. Une arène possède un bloc de mémoire native et le libère à sa fermeture. Le with-open de Clojure fait ce nettoyage automatiquement en fin de bloc. Si vous vous trompez, vous n'obtenez pas d'exception. Vous obtenez un segfault.

Un premier appel est modeste. Charger zlib et demander sa version renvoie la chaîne 1.3.1.

Pourquoi l'exemple SQLite compte

L'exemple que met en avant Borkent n'est pas un jouet. La FFI permet de définir une fonction Clojure et de l'enregistrer dans une base de données native, afin qu'une requête SQLite l'appelle pendant son exécution.

C'était impossible avec les pods. Un pod tourne dans son propre processus, et SQLite ne peut pas traverser un socket au milieu de l'évaluation d'une requête. La fonction doit vivre dans le même processus que le moteur de base de données. La FFI directe l'y place.

C'est la forme générale du changement. Tout ce qui exige que votre code et la bibliothèque native partagent un processus et un espace mémoire était hors de portée. Callbacks, allocateurs personnalisés et points d'extension en processus s'ouvrent maintenant.

Un changement plus discret sur les binaires Linux

Une ligne de la version concerne aussi ceux qui ne toucheront jamais à la FFI. Sous Linux, la compilation par défaut de Babashka passe de entièrement statique à majoritairement statique, ce qui signifie que la glibc est désormais liée dynamiquement. Les versions macOS et Windows fonctionnaient déjà ainsi.

La raison est la FFI elle-même : charger des bibliothèques natives arbitraires à l'exécution s'accorde mal avec un binaire entièrement statique. Le prix est la portabilité. Un binaire entièrement statique s'exécute partout ; un binaire majoritairement statique attend une glibc compatible sur l'hôte. Si vous copiez Babashka dans un conteneur minimal ou une image Alpine, testez avant de mettre à jour.

Ce que cela signifie pour les développeurs

Si vous utilisez déjà Babashka pour vos scripts et que vous évitiez une tâche parce qu'elle réclamait une bibliothèque C, réexaminez-la. Le détour par les pods était une vraie friction, et il a disparu.

Si vous maintenez un pod, lisez cette version de près. Les pods gardent leur intérêt pour l'isolation et pour envelopper de gros SDK natifs. Ils n'en ont plus quand il s'agit seulement d'atteindre quelques fonctions C.

Si vous débutez, commencez par les règles des arènes plutôt que par la syntaxe d'appel. Appeler zlibVersion est facile. Savoir quelle mémoire vous possédez, et quand elle est libérée, sépare un script qui marche d'un plantage intermittent. Enveloppez chaque arène dans with-open tant que vous n'avez pas de raison de faire autrement.

Et si vous déployez Babashka en conteneur, vérifiez la glibc de votre image de base avant de passer à 1.13.220. Ce changement arrive que vous utilisiez ou non la nouvelle interface.