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)
Have you seen my cream project?
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.
what you describe above is basically what Crema is for, a new byte code interpreter for native-images
and cream uses that
Yeah, sorry, my mind sort of wandered off to that polyglot world. Cream is definitely interesting... something new with which to experiment.
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
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. 🙂
yeah for CLJS for sure
also for sandboxing purposes still
the binary size of cream is now 187 or so
since it can execute bytecode maybe it can stay around this size and the rest of the deps can be run at runtime
but some benchmarks showed that bb is still even faster at loading deps
perhaps I'll rename cream to bb2 at some point, we'll see
Would that involve bundling the bb functionality (I'm especially thinking about tasks) in, or leaving it to be used as a dependency?
I can make it bb compatible once I know for sure this is where I want bb2 to be headed
like tasks, not so difficult to bring that into cream