Closed FieryCod closed 3 years ago
Could you explain what the arguments mean here: clojure,next,camel_snake_kebab
-- are they essentially wildcards so that clojure.*
, next.*
, etc get initialized at build time?
Since that resources
tree is only needed when building for Graal, shouldn't it be under an alias, or is the intent that this gets added automatically for users of this library when they build a native application that includes it?
Could you explain what the arguments mean here: clojure,next,camel_snake_kebab -- are they essentially wildcards so that clojure., next., etc get initialized at build time?
Sure. The thing is that GraalVM initializes some classes at build time (when running native-image compilation). The output of such compilation is a binary. The startup is extremely fast because some of the classes are already initialized in the binary. Now all the Clojure packages have to be initialized at build time, which means that next_jdbc + the dependencies should be declared as initialized at build time. They are like wildcards indeed.
Since that resources tree is only needed when building for Graal, shouldn't it be under an alias, or is the intent that this gets added automatically for users of this library when they build a native application that includes it?
No. The configuration is automatically taken by native-image tool. Merging this PR is beneficial for end users, because no additional actions are required for them to make next_jdbc work with GraalVM native-image.
Thank you!
Dear @seancorfield. The following configuration is the only requirement to make next.jdbc work with GraalVM. The configuration has already been tested by Eric Dallo and the automated pipeline https://github.com/clj-easy/graal-config
Although the configuration is already hosted in graal-config, the clj-easy organization recommends to distribute the configuration from the library artifact.