Fork me on GitHub
#graalvm
<
2022-02-02
>
jm12:02:26

hey I’m new to building native-images, we are just experiencing with it at work. A quick q: has anyone had to compile joda-time into a native-image? And if so how could you make it work?

jm12:02:22

the latest error I’m getting:

Error: Class initialization of org.joda.time.UTCDateTimeZone failed.
Caused by: java.lang.NullPointerException: Cannot invoke "String.hashCode()" because the return value of "org.joda.time.UTCDateTimeZone.getID()" is null

ericdallo12:02:56

Probably some code that runs on toplevel which doesn't work good with graalvm, maybe you can delay the class initialization to runtime?

jm12:02:28

let me try that

borkdude12:02:34

You should really be using #clj-easy graal-build-time which will only initialize clojure code at build time

ericdallo12:02:09

but if his lib use joda time there is no other way right?

borkdude12:02:13

And another thing: why use joda-time if there's java.time?

☝️ 1
borkdude12:02:33

it depends if that lib is initializing classes on the top level or not

jm12:02:14

yeah, I’m trying to use clj-easy , great stuff btw 🙂

jm12:02:51

absolutely agree about java.time, but unfortunately we have some legacy code which uses joda-time

jm12:02:26

and this project is a POC for using native-image so getting rid of joda-time is not in the scope

jm12:02:45

ofc maybe that would be easier 🙂

Toby Clemson12:02:54

Not sure this is helpful, but I had exactly this problem, spent a whole lot of time trying different things to resolve, and in the end, gave up and migrated to java.time.

jm12:02:22

sure, that helps 🙂 one more reason not to fight with it

borkdude12:02:48

you'll migrate at one point in the future anyways, so you might as well bite the bullet now :)

👍 2