Hiya @U0K064KQV! GraalVM native image is getting smoother and faster with each release. Apparently, a native image can now be as fast as running on the JVM. There is still no cross-compilation. There are 2 versions of GraalVM: Oracle and Community. The Oracle variant (the one with optimizations) is now also free to use but has a different license than the Community variant. If you are more specific with your finicky Java constructs question, maybe someone can chime in with an answer.

I just remembered that things that were too dynamic, reflection, etc. was challenging.

And so like, I think borkdude had to rewrite certain libs to make them work with native-image

All reflection issues I've ran into are possible to mitigate, albeit somewhat annoying at times.

Bytecode modification on the fly cannot be supported, so modification of code via reflection, creating new classes etc cannot be done under native-image. It's called closed world assumption. I believe Oracle variant has support for profile guided optimization, which usually delivers slightly better results in production workflows. But for most utilities that we write here this is not that much of a value in my opinion.

reflection can be done btw, using the correct config

all babashka interop is in fact implemented using reflection

I guess it's read-only kind of reflection right? So no dynamic proxies etc.

yes

ok it can even do dynamic proxies, but it has to have all usages covered... that's pretty impressive

mindblowing

I believe it basically boils down to having all under "closed world assumption"

When you say native image can be as fast. Does that even count cpu bound tasks that benefit a lot from JIT?

Also is there any good resources on inclusion of Python/JS libs in a Clojure project? When I looked in the past it had a lot of friction so I avoided it.