I'm trying to serialize a class's properties as an array rather than a map. How can I do this while ...

# serialization

[jw]

I'm trying to serialize a class's properties as an array rather than a map. How can I do this while maintaining support for handling default values correctly (and in compliance with configurations like JSON's encodeDefaults boolean)?

[jw]

I'm actually not sure if this is possible. I have no way of invoking the synthetic constructor and setting default bits. Does the regular codegen do that?

[Adam S]

hi, does this issue comment help? https://github.com/Kotlin/kotlinx.serialization/issues/1906#issuecomment-1229225113

[jw]

I was trying to avoid JsonTupleSerializer since this code is already somewhat performance sensitive, although maybe it won't make a huge difference. I don't actually have benchmarks in place to validate just what kind of an impact it would have.

[jw]

The reason for wanting to use arrays is that I (mostly) trust both sides of the serialization because it's the same code running in both places. And JSON is so noisy with its keys it just wastes space...

[Emil Kantis]

Aren't the payloads usually gzip'd? Not sure it's worth the effort to get rid of the keys. It might also make logs harder to decipher, etc

[jw]

i am not crossing a network boundary

[jw]

also there's no logs

[Emil Kantis]

Gotcha 🙂

[jw]

this is for crossing JNI, basically. going from one memory space to another.

[jw]

it is, admittedly, a little weird in requirements as a result!

[Adam S]

maybe a custom format, like CSV or FLF? https://github.com/hfhbd/kotlinx-serialization-csv

[Adam S]

I’ve used KxS with Kafka Streams and I copied (with minor adjustments) the efficient binary format from the docs. It’s so much faster than JSON. It does mean that I can’t easily view the in-flight messages though.

[jw]

Yes, an alternate format is possible. However, we currently rely on JsonElement for creating holes in the serialized form that user code can plug in arbitrary values to bring across the boundary encased in the semantics of our protocol. There's nothing impossible for doing that in binary a format as it could be a ByteArray, but it's nice having a semi-structured element still.

[jw]

And I realize that's somewhat ironic

[jw]

Anyway I'm perfectly happy to use a JSON transformation for now as I'm confident we have a pathway to more efficient serialization code both while keeping JSON or through switching formats.

[Dominaezzz]

Are any of the properties optional?

[jw]

yes

[Dominaezzz]

Is that even possible? Ah, I'm guessing you want the optional properties to be encoded as null as supposed to being omitted from the array.

[jw]

there's only a single optional property and it's always encoded last

[Dominaezzz]

Definitely custom serializer territory.
Your descriptor would be serialDescriptor<JsonArray>() .
Compliance with encodeDefaults should be possible by calling https://github.com/Kotlin/kotlinx.serialization/blob/master/core/commonMain/src/kotlinx/serialization/encoding/Encoding.kt#L352 .

[Dominaezzz]

Collection serializers are quite easy to write especially when you know the size (+/- 1).