Serialization Formats
The concrete formats — JSON, binary encodings — plus custom serializers, polymorphic encoding, and evolving a schema without breaking old clients. Compatibility is the part interviewers actually care about.
part ofKotlinoverview, primer and where to startread it →on this pageshowhide
explore
- JSON Configuration (Json {})6 questions
- JsonElement & Dynamic JSON5 questions
- Binary Formats (ProtoBuf, CBOR)5 questions
- Custom Serializers6 questions
- Sealed-Class Polymorphic Serialization5 questions
- Schema Evolution & Defaults5 questions
- Deserialization Safety5 questions
questions
page 2 of 2kotlinx.serialization supports more than one way of laying out polymorphic data on the wire. Explain ARRAY_WRAPPED vs the discriminator object mode, and when you must use which.
basics
~20 sNormally the type name is a field inside the object (discriminator mode). But that only works when the value is a JSON object. For non-object values (like a primitive), the library wraps it as a two-element array [typeName, value]. You can also force array mode.
When hand-writing a serializer, how do you correctly handle nested serializable values and nullable fields? Contrast encodeSerializableValue with encodeNullableSerializableElement.
basics
~20 sFor a nested object, hand the encoder the nested type's own serializer instead of encoding fields yourself. For a field that may be null, use the nullable-element methods so null is written and read correctly instead of crashing.
How do Json configuration flags like ignoreUnknownKeys, coerceInputValues, isLenient, and decodeEnumsCaseInsensitive affect the security/trust posture of deserializing untrusted input?
basics
~10 sThese flags make the parser more forgiving. Forgiving is convenient but can silently accept or change attacker data. For untrusted input, prefer strict settings so unexpected data fails loudly instead of slipping through.
What are the immutability, equality, and ordering guarantees of JsonObject and JsonArray, and what gotchas arise when you treat JsonObject as a Map (e.g. number representation)?
basics
~20 sJsonObject and JsonArray are immutable. JsonObject acts like a Map and keeps insertion order; equality compares contents. A common gotcha: numbers are stored as text inside JsonPrimitive, so 1 and 1.0 are different primitives and aren't equal.
You have a sealed @Serializable Result<T> hierarchy and you also nest one sealed type as a property of another. What subtleties arise with discriminator collisions, generic type arguments, and decoding the base vs a concrete subtype?
basics
~20 sPolymorphic encoding only happens when you serialize through the base type, not a concrete subtype. Generic type arguments still need their own serializers, and a nested sealed property must itself be polymorphically encoded. The discriminator key must not collide with a real field name.
How should you design and manage Json instances across an application — strictness for inbound vs outbound, reuse, and copying configuration?
basics
~20 sCreate a few shared, reusable Json instances configured for their job: strict for output, tolerant (ignoreUnknownKeys) for input. Don't build Json { } per call, and derive variants with Json(from = base) { ... }.
You need to rename a serialized field across versions without breaking already-stored or in-flight payloads. Using kotlinx.serialization mechanics in this leaf, how do you stage that evolution safely?
basics
~10 sDon't hard-rename. Add the new field with a default, keep accepting the old one, ignore unknown keys during transition, then drop the old field only after all old payloads are gone.
showing 31–37 of 37