instaparse-bb is there because instaparse's clojure code does not run in bb

💡 ah. so the pod uses the “JVM-clojure”, and that’s that. thanks

no, the instaparse-bb library uses the instaparse pod which is compiled to native binary for fast startup, it does not use a jvm

💡💡

😳 thanks again. that’s cool.

other examples of "jvm compiled to native pods" can be found here: https://github.com/babashka/pod-registry

OK since I’m asking so many questions already — is this correct: BB is using SCI, and it’s using graal’s native-image, isn’t it? so the libs we’re talking about work with graal compiling them to a native binary because graal is JVM compatible where SCI is not (not 100% I mean)?

SCI only supports executing a subset of Clojure from source.

Another way is to include instaparse as a built-in library in babashka, this works

but since I don't want to include the whole ecosystem, since this would result in longer compile times and a bigger bb binary, pods are another way to get the same functionality

ah ok. sorry, it’s just all those intricacies I’ve not fully wrapped my head around (yet)

and I like pods. 😄 (and this helps me appreciate them even more.)

The java interop must be provided to sci so it can use it. bb provides the most common amount of it, but not all of java. Some clojure libs use either directly or transitively some parts of java not included in bb and thus not exposed to its sci interpreter. That does not mean those libs use java code that cannot be native compiled. So they can still be bundled as a pod.