babashka-sci-dev

Bob B 2026-03-08T23:30:11.340619Z

pure curiosity question - I was poking around in some docs, and I came across Espresso/"Java on Truffle" from the graalvm folks: <https://www.graalvm.org/latest/reference-manual/espresso/>. Very cursorily, it purports to allow for using java code "dynamically" in a native image (i.e. overcoming the "closed-world" situation). I was just curious if anyone has considered if it'd be at all viable to leverage this to allow for using java libraries (or even just loading JDK classes) that aren't bundled into/exposed by babashka. I haven't thought through much in the way of actual implementation - I imagine it'd probably be fairly complex, because it'd probably involve using a Truffle context, and maybe that's a non-starter. Any interest in a GH discussion or anything? ("no" is a totally reasonable answer)

borkdude 2026-03-09T07:00:57.282099Z

Have you seen my cream project?

Bob B 2026-03-09T19:45:55.384329Z

I hadn't, but I'm looking over it now. This sort of led me into thinking about what it'd look like to try and use clojure in the context of Truffle's polyglot API, but that idea is incredibly not-fleshed-out in my head.

borkdude 2026-03-09T19:47:49.112889Z

what you describe above is basically what Crema is for, a new byte code interpreter for native-images

borkdude 2026-03-09T19:47:57.237559Z

and cream uses that

Bob B 2026-03-09T19:58:24.434309Z

Yeah, sorry, my mind sort of wandered off to that polyglot world. Cream is definitely interesting... something new with which to experiment.

borkdude 2026-03-09T20:00:12.159569Z

it's not as lean as bb and also bb is still faster for most things currently, but this might change with ristretto, a JIT for crema. it's kind of sad that this replaces the need for SCI for native-images, since I enjoy working on SCI... the binaries are also bigger / take longer to compile. so there's some trade-offs, but most people don't care about how big a binary is and how long it took someone else to compile

Bob B 2026-03-09T20:06:15.898469Z

I guess if the binary size doesn't get too wild, and maybe it eventually totally replaces the need for a JVM for bb to fetch deps and what not, then maybe it's somewhat justified. But also, I feel like SCI has enough tendrils to keep it going for quite a while, right? I mean, I still revel in the fact that I was able to cram a clojure runtime into GNOME's JS execution engine. 🙂

borkdude 2026-03-09T20:06:47.571979Z

yeah for CLJS for sure

borkdude 2026-03-09T20:06:58.369489Z

also for sandboxing purposes still

borkdude 2026-03-09T20:07:29.685519Z

the binary size of cream is now 187 or so

borkdude 2026-03-09T20:07:53.524519Z

since it can execute bytecode maybe it can stay around this size and the rest of the deps can be run at runtime

borkdude 2026-03-09T20:08:12.471749Z

but some benchmarks showed that bb is still even faster at loading deps

borkdude 2026-03-09T20:09:30.349019Z

perhaps I'll rename cream to bb2 at some point, we'll see

Bob B 2026-03-09T20:14:28.995529Z

Would that involve bundling the bb functionality (I'm especially thinking about tasks) in, or leaving it to be used as a dependency?

borkdude 2026-03-09T20:15:06.855239Z

I can make it bb compatible once I know for sure this is where I want bb2 to be headed

borkdude 2026-03-09T20:15:24.898669Z

like tasks, not so difficult to bring that into cream