Has anyone tried using serialization with Graalvm compiled to a native image?

# serialization

[Greg Steckman]

Has anyone tried using serialization with Graalvm compiled to a native image?

[Big Chungus]

Should not be an issue since it's reclectionless

[Greg Steckman]

Hmm ok.

[Greg Steckman]

I tried adding MyClassName$$serializer explicitly, but it doesn't work.

[Greg Steckman]

I get the "Serializer for class is not found" error.

[Greg Steckman]

However if I use the form of encode/decode that takes a serializer as first parameter, it seems to work fine.

[Big Chungus]

Decompile generated bytecode to get a better sense where exactly compiler plugin places generated serializer

[Greg Steckman]

which class do you think I should decompile?

[Big Chungus]

The one you annotated

[Greg Steckman]

ok. I'll take a look. I was assuming it was in the *$$serializer.class(es) that are generated.

[Greg Steckman]

If you use MyClass.serializer().javaClass.name, it's what you get.

[Big Chungus]

Did you try running graalvm diagnostic tool to see what configs it generates for you?

[Greg Steckman]

I'm new to graalvm. I used --verbose and -H:+ReportExceptionStackTraces.

[Greg Steckman]

I was looking for that type of option in the docs, but that's what I came up with. Do you have any additional suggestions?

[Big Chungus]

It's called tracing agent https://medium.com/graalvm/working-with-native-image-efficiently-c512ccdcd61b#7b46

[Big Chungus]

Very neat tool to get you started

[Greg Steckman]

Yes I saw that. One complication is I'm writing a lambda function, so not sure if I can use it in a lambda JVM environment. But I can certainly write a test case using serialization and run it locally.

[Big Chungus]

Yes, you only need to run that piece of code to let the tool detect missing configs

[Big Chungus]

Final executable would still be a native image for your lambdas

[Greg Steckman]

thanks for the suggestion

[Big Chungus]

Good luck!

[ephemient]

inline fun <reified T> StringFormat.encodeToString looks up the serializer by name - this JVM-only helper does involve some reflection - while fun <T> StringFormat.encodeToString uses the serializer you pass in. I can imagine the former not working on GraalVM but the latter should be fine in all environments as everything is referenced statically

[Big Chungus]

In that case tracing agent should sort you out

[Greg Steckman]

The tracing agent did the trick. For each serializable class two entries need to be added to the reflect-config.json file.

[Big Chungus]

Can you share your reflect config for the future explorers here?

[Greg Steckman]

Here are the needed entries if using the example from https://github.com/Kotlin/kotlinx.serialization:

{
  "name":"Project",
  "fields":[{"name":"Companion"}]
},
{
  "name":"Project$Companion",
  "methods":[{"name":"serializer","parameterTypes":[] }]
}

[Greg Steckman]

Is there any way to configure serialization to not use reflection when on the JVM?

[Greg Steckman]

I didn't see anything with a quick search of the guide.

[Big Chungus]

Well if you always pass in serializers explicitly ir won't

[Big Chungus]

But you can't enforce that, unfortunately

[Big Chungus]

Well you could always write a detekt rule for this I guess 😀

[Greg Steckman]

It's probably easier to explicitly pass in serializers than maintaining a reflect-config.json file.

[Greg Steckman]

Just makes the code a little less nice.

[Big Chungus]

I'd go for reflectionless serialization myself

[Big Chungus]

To enforce it you could write a quick gradle task that checks your source files as plain text and fails if it detects an import of that reflection helper function

[Big Chungus]

OR, move all your serialization code to commonMain where reflection is not even available

[ephemient]

https://github.com/Kotlin/kotlinx.serialization/issues/1125 looks like they intend for it to work "soon", but it's been a year 🤷