[dig1]

True, but you don't develop that way using graal. You develop java apps the usual way (eclipse, emacs/vim/maven, whatever) and create a fat jar (or uberjar). When you make sure the application is working, compile it with graal, creating a static binary.

Clojure cycle is even faster because you keep REPL open and evaluate code directly while application is running. After that, you build uberjar, then compile it with graal.

[uDontKnowMe]

Would there not be a risk that you may get something working nicely in openjdk and then you go to do a native compilation, and it turns out that it doesn't work due to some new method call which uses reflection or something?

[didibus]

Reflection is supported by GraalVM native compilation, but you need to declare what classes you need reflection support for at compilation.

What you must understand though, is that you're asking for something contradictory. You cannot get runtime eval and code linking and also deliver a statically linked compiled machine code binary.

That's why statically linked to machine code binary languages don't offer dynamic code generation, linking and reflection that can't be declared or performed at compile time.

This is true for GraalVM. It means when you develop Clojure for GraalVM native compilation you can't leverage such dynamic behavior as well.

Though you can embed the SCI Clojure interpreter inside your application and do dynamic code evaluation with it at runtime.

[jgrodziski]

GraalVM issue an error if it can't resolve the proper method call or if another Thread is involved in the computation so I find it pretty safe to use. Of course, GraalVM doesn't exempt you from doing some tests.