Over the years I have seen repeated discussions about how to handle streams, ByteArrays, or other mo...

# serialization

[Gary Spreder]

Over the years I have seen repeated discussions about how to handle streams, ByteArrays, or other more forms which don't require a full copy of the bytes into in-memory decoded String before processing. Overall, the prevailing conclusion seems to be "If you have bytes, use X instead" (typically Moshi). This is despite a streaming API existing for a few years now in an "experimental" status.

Is there a long-term plan for support? I can find no clear mention or plan around this set of features on any roadmap or official docs. Should I assume that streaming is too far away from kotlinx.serialization's core strengths, and the streaming support will likely never reach maturity?

In a library, I cannot reasonably leverage an experimental API. Character-based decoding is the majority of what I need, but the most performance-critical portion works in streams (unsurprisingly). kotlinx.serialization is beautiful and a great fit in so many other ways, but the performance hit on binary parsing is simply brutal.

What barriers remain before the kotlinx.serialization streaming API can be marked stable?

[jw]

kotlinx-io would have to 1.0

[Gary Spreder]

Which remain on the Kotlin roadmap, and out of this library's hands. Got it.

Verbose question, beautifully terse answer. Thanks Jake.

[jw]

The maintainers basically commented as such here: https://github.com/Kotlin/kotlinx.serialization/issues/253#issuecomment-2158956453

[jw]

Streaming will become the core behavior and buffered will change to be built on top of that, but that requires kotlinx-io become stable

[Gary Spreder]

That makes sense and seems ideal. And that ticket was marked as closed by an MR mere hours ago. 🎉

Great news, thanks again.