Fork me on GitHub

Maybe this will interested someone: This is a Nix Flake with multiple versions for GraalVM, including native-compile, graalpython, TruffleRuby, etc. I succesfully compiled Babashka static using it


Since it is a flake, you can use something like this to get it started: nix run "git+" -- --help This will run native-image for graalvm11-ce with support for musl (and musl only, glibc builds are broken)


If you use nix run "git+" -- --help, this will run native-image for graalvm11-ce and glibc (no musl support)


If you want to have a quick shell with graalvm11-ce and all binaries, nix develop ""git+" should work


that's amazing! great work!


If that works well, maybe @U04V4KLKC could think on making the Github actions use this? as it's pure

Karol Wójcik16:10:04

I have started porting some of the holy-lambda examples to GraalVM 21.3.0, and I'm seeing that libraries which didn't require additional --initialize-at-build-time before, now require it. For instance data.xml now requires a lot of --initialize-at-build-time flags.,,,,,jdk.xml.internal.JdkXmlUtils,javax.xml.parsers.FactoryFinder,jdk.xml.internal.SecuritySupport,,,,,,,,javax.xml.datatype.DatatypeFactory
I'm thinking whether Clojure core would accept tiny patches with such configuration or should we keep distributing the configuration via graal-config for core.


@UJ1339K2B Are you sure this is in data.xml? I'm using this in bb and I didn't have to do this. Are you sure your code or one of your libs doesn't instantiate any XML things on the top level?

Karol Wójcik17:10:51

I'm just trying to confirm it in graal-config. The code I tried to compile is using cognitect aws api, but I'm not seeing any usage of data.xml on top level. see:


why don't you just add .apache.xerces and javax.xml

Karol Wójcik18:10:05

Shouldn't we specify only the classes that the particular library use instead of saying "build all the classes from the namespace xyz"?

Karol Wójcik18:10:23

Btw found a reflection as well:

(defn -main
  [& _args]
  (println (xml/parse-str
            (xml/emit-str (xml/sexp-as-element
                           [:foo {:foo-attr "foo value"}
                            [:bar {:bar-attr "bar value"}
                             [:baz {} "The baz value"]]])))))
Exception in thread "main" java.lang.IllegalArgumentException: No matching method createXMLStreamReader found taking 1 args for class


Optimally yes, but previously you also initialized everything at build time so this is already an improvement ;)


I think we can make a fork of this lib to be honest, to yield much smaller graalvm binaries


the dynaload thing is causing image bloat


but it wasn't high on my list since it doesn't affect bb directly, only the pod


this library is just one glorified http call library mostly


that should not take 100mb


I think the size can be reduced to 30mb or so

Karol Wójcik18:10:10

Eh. As always you are right. This has something to do with aws api. I will trace the initialization.