Hello folks! I am interested in leveraging `kotlin...
# serialization
a
Hello folks! I am interested in leveraging
kotlinx-serialization-protobuf
in an upcoming project at my job, but I see that the status for the format is still "experimental". Is there a timeline for when this will be production ready?
b
I would not let that keep you. Especially if your next project will be open source, you can use the swarm intelligence here to help with any kinks you might encounter
a
It will be proprietary
b
Still, experimental does not mean buggy or unstable. Just means api is not 100% fixed
☝️ 2
v
hey, no timelines for that, right now it is basically in perpetual experimental state waiting for its hero. Most issues revolve around proto3 semantics (where everything can be optional but there are no default values; the opposite of Kotlin in cases like
@Serializable class Foo(val bar: Bar = Bar(), val int: Int = 42)
. The proto2-centric core is stable and reasonably tested (including fuzzing), unlikely to change
❤️ 1
a
Thanks @Vsevolod Tolstopyatov [JB] for the explanation!
j
The issue Vsevolod mentions is that Proto3 defaults are implicit (
fields are omitted if they are 0 or ""
), but Kotlinx Serialization uses Proto2 semantics by default (see: formats.md#protobuf) and throws a MissingFieldException if a field is missing from the wire and has no explicit default in Kotlin. For binary protobuf, this forces you to write explicit defaults for every property in your data class, or use Square's Wire. If what you need is canonical Proto3 JSON mapping and you're willing to try alternatives, we solved this mismatch in our project ghost-serializer (ghost-protobuf). It handles zero-value omissions and WKTs out of the box.
p
As said, experimental is mostly about API stability and completeness. It is not likely that the functionality use will use will be removed (unless it is actually broken), but as said, giving feedback is really helpful.