Clojurians Log v2

@borkdude: I was wondering if you’ve seen this:

https://www.graalvm.org/reference-manual/native-image/BuildConfiguration/#embedding-a-configuration-file

I have seen that

Which looks to me like you can essentially generate the graal reflect configs etc and bundle them in library jars

yes, true

This seems a fundamentally better way to do things

e.g. httpkit could just bundle that, rather than listing config for users to use in their README

https://github.com/http-kit/http-kit/issues/463#issuecomment-814915168

hehe ok always one (thousand) step(s) ahead 🙂

If you feel like doing a PR :)

lol 😆 if I had a dependency on http-kit right now I might just

@borkdude: So I’m thinking it would be nice for clojure graal library templates to bundle this sort of thing by default. If every lib created by something like this: https://github.com/seancorfield/clj-new/blob/develop/src/clj/new/lib.clj Included the META-INF/native-image/ as generated config that stated something like --initialize-at-build-time={{package-namespace}}, then most clojure libraries (at least ones without interop) would work in graal apps out of the box with less burden on the app creator

yeah. on the other hand, it's brittle to assume that people are going to do this. I think I'll just add that little snippet to bb.edn here: https://github.com/borkdude/jayfu

also it's going to be tedious if every clojure maintainer should have to do this, for every new namespace. like documentation it's always going to be out of sync

instead I'll probably make a template out of jayfu if I'm satisfied enough with it

yeah I agree we also need tooling… But is it really for every new namespace? Most libs are bundled with all their namespaces inside a common parent, so wouldn’t it be sufficient for most libs to just mention generate that at template instantiation time?

jayfu is new to me… If I’d known about this a month ago 😆

yeah, that's true, but still. only a small portion of Clojurians are using graalvm native-image so for many people this will just be something confusing maybe

there is a talk coming by ClojureD

soon online, I mean

I suspect DynamicClassLoader can be substituted to "do nothing" https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/DynamicClassLoader.java Perhaps that results in something useful

so we're able to do everything "at runtime"

:thinking_face: Yeah just changing to use SecureClassLoader or URLClassLoader might be sufficient

ah well, this is a research project for another time