metosin / jsonista

Clojure library for fast JSON encoding and decoding.
https://cljdoc.org/d/metosin/jsonista
Eclipse Public License 2.0
422 stars 30 forks source link

Provide GraalVM native-image --initialize-at-build-time args #58

Closed FieryCod closed 3 years ago

FieryCod commented 3 years ago

As clj-easy/graal-build-time states:

From GraalVM 22 onwards, the native-image global --initialize-at-build-time option will be deprecated. This means you will have to list every package that you want to initialize at build time separately, like initialize-at-build-time=clojure,my_library

Without now discouraged --initialize-at-build-time with no arguments passed the native-image tool fails to build the project that depends on metosin/jsonista. This is due to the fact, that some of the com.fasterxml.jackson classes are initialized unconditionally in core.clj.

The following changes auto provides the necessary jsonista configurations to GraalVM native-image, are backward compatible for all GraalVM jsonista users, and should not introduce any breakage.

borkdude commented 3 years ago

Look good to me. Perhaps also add "resources" to:paths` in deps.edn.

FieryCod commented 3 years ago

@borkdude do you see everything I do on Github? :eyes: :laughing:

Actually, I can update deps.edn to match the dependencies, resources of project.clj if necessary. Should I @ikitommi?

borkdude commented 3 years ago

I am subscribed to jsonista issues ;).

ikitommi commented 3 years ago

Updating the dependencies in two places is no fun, it would be better to lift this as deps-project. PR most welcome on that. (jmh-test too)

FieryCod commented 3 years ago

Huh. That was fast. Could we please release the new version of jsonista with just this change? :pray:

opqdonut commented 3 years ago

https://clojars.org/metosin/jsonista/versions/0.3.4

let me know if that works for you

FieryCod commented 3 years ago

Works perfectly fine:

...
-imagecp \
/opt/graalvm-ce-java8-21.2.0/jre/lib/boot/graaljs-scriptengine.jar:/opt/graalvm-ce-java8-21.2.0/jre/lib/boot/graal-sdk.jar:/project/.holy-lambda/build/output.jar:/opt/graalvm-ce-java8-21.2.0/jre/lib/svm/library-support.jar \
-H:Path=/project/.holy-lambda/build \
'-H:Class@manifest from file:///project/.holy-lambda/build/output.jar=com.compan
y.example_lambda.core' \
'-H:Name@manifest from file:///project/.holy-lambda/build/output.jar=output' \
'-H:ClassInitialization@jar:file:///project/.holy-lambda/build/output.jar!/META-
INF/native-image/metosin/jsonista/native-image.properties=com.fasterxml.jackson:
build_time' \ <-- SEE HERE
'-H:ClassInitialization@jar:file:///project/.holy-lambda/build/output.jar!/META-
INF/native-image/metosin/jsonista/native-image.properties=jsonista:build_time' \ <-- SEE HERE
-H:ConfigurationFileDirectories=native-configuration \
-H:FallbackThreshold=0 \
-H:EnableURLProtocols=http,https \
-H:+ReportUnsupportedElementsAtRuntime \
-H:+AllowIncompleteClasspath \
-H:CLibraryPath=/opt/graalvm-ce-java8-21.2.0/jre/lib/svm/clibraries/linux-amd64
]

Thank you so much @ohpauleez @ikitommi @borkdude :)

borkdude commented 3 years ago

Just as a FYI:

This is due to the fact, that some of the com.fasterxml.jackson classes are initialized unconditionally in core.clj.

This can usually be prevented by wrapping those top-level-ns instances in delays. If that's possible, this is the preferred solution, but this would perhaps break users of those top-level vars.