Babashka 1.13.220 bringt FFI für native Bibliotheken

Babashka, die schnell startende Clojure-Skriptumgebung, kann jetzt native C-Bibliotheken direkt aufrufen. Version 1.13.220 erschien am 31. August 2026 mit einem Foreign Function Interface, und Autor Michiel Borkent erklärte den Entwurf in seinem Blog. Bisher hieß nativer Code aus einem Babashka-Skript: ein Pod schreiben, also ein eigenes Programm, mit dem Babashka über einen Socket spricht. Das FFI streicht diesen Schritt.

Ein Foreign Function Interface ist die Verbindung, über die eine Sprache eine andere aufruft. Hier ruft Clojure C auf.

Was die neue Schnittstelle tut

Die Umsetzung baut auf java.lang.foreign auf, der Foreign Function and Memory API, die über Project Panama ins JDK kam. Borkent merkt an, dass die bestehende Bibliothek coffi auf derselben Grundlage aufsetzt. Es ist also kein Eigenbau, sondern der offizielle Weg der JVM zu nativem Code, geöffnet für Skripte.

Das Release umfasst mehr als einfache Funktionsaufrufe. Laut den Release Notes auf GitHub erstreckt sich die Arbeit über die Pull Requests #2031 bis #2077 und enthält Memory Segments, Arena-Verwaltung, Layouts für Structs und Unions sowie Callbacks. Callbacks sind wichtig: Damit ruft eine C-Bibliothek Ihren Clojure-Code zurück.

Der Speicher verlangt Aufmerksamkeit. Nativer Speicher liegt außerhalb der Garbage Collection, deshalb verwaltet man ihn in Babashka ausdrücklich über Arenas. Eine Arena besitzt einen Block nativen Speichers und gibt ihn beim Schließen frei. Clojures with-open erledigt dieses Aufräumen am Ende eines Blocks automatisch. Macht man es falsch, gibt es keine Exception. Es gibt einen Segfault.

Ein erster Aufruf ist klein. Lädt man zlib und fragt die Version ab, kommt die Zeichenkette 1.3.1 zurück.

Warum das SQLite-Beispiel zählt

Das Beispiel, das Borkent hervorhebt, ist kein Spielzeug. Mit dem FFI lässt sich eine Clojure-Funktion definieren und in einer nativen Datenbank registrieren, sodass eine SQLite-Abfrage sie während der Ausführung aufruft.

Mit Pods ging das nicht. Ein Pod läuft im eigenen Prozess, und SQLite kann mitten in der Auswertung einer Abfrage nicht über einen Socket greifen. Die Funktion muss im selben Prozess liegen wie die Datenbank-Engine. Direktes FFI bringt sie dorthin.

Das ist die allgemeine Form der Änderung. Alles, wofür Ihr Code und die native Bibliothek einen Prozess und einen Speicherraum teilen müssen, war bisher unerreichbar. Callbacks, eigene Allokatoren und prozessinterne Erweiterungspunkte stehen jetzt offen.

Eine leisere Änderung an den Linux-Binaries

Eine Zeile im Release betrifft auch alle, die das FFI nie anfassen. Unter Linux ist der Standard-Build von Babashka von vollständig statisch auf überwiegend statisch gewechselt, das heißt: glibc wird jetzt dynamisch gelinkt. macOS- und Windows-Builds arbeiteten schon vorher so.

Der Grund ist das FFI selbst: Beliebige native Bibliotheken zur Laufzeit zu laden verträgt sich schlecht mit einem vollständig statischen Binary. Der Preis ist Portabilität. Ein vollständig statisches Binary läuft überall; ein überwiegend statisches erwartet eine passende glibc auf dem Host. Wer Babashka in einen minimalen Container oder ein Alpine-Image kopiert, sollte vor dem Upgrade testen.

Was das für Entwickler bedeutet

Wer Babashka schon für Skripte nutzt und eine Aufgabe gemieden hat, weil sie eine C-Bibliothek brauchte, sollte sie sich noch einmal ansehen. Der Umweg über Pods war echte Reibung, und er ist weg.

Wer einen Pod pflegt, sollte genau lesen. Pods ergeben weiterhin Sinn für Isolation und für das Umhüllen großer nativer SDKs. Sie ergeben keinen Sinn mehr, nur um eine Handvoll C-Funktionen zu erreichen.

Wer neu einsteigt, beginnt besser bei den Arena-Regeln als bei der Aufrufsyntax. zlibVersion aufzurufen ist leicht. Zu wissen, welchen Speicher man besitzt und wann er freigegeben wird, unterscheidet ein funktionierendes Skript von einem sporadischen Absturz. Packen Sie jede Arena in with-open, bis es einen Grund dagegen gibt.

Und wer Babashka in Containern ausliefert, prüft vor dem Sprung auf 1.13.220 die glibc im Base Image. Diese Änderung kommt mit, ob Sie die neue Schnittstelle nutzen oder nicht.