It is not going to be “built in”, but the serialization framework will provide library writers with some tools to implement it. However, in order to validate the design of the serialization framework we need to prototype a couple of such libraries ourselves to make sure that the corresponding features are indeed implementable in the framework we are delivering. That is why we need real-life use-cases. We are not going to hard-code them into the stdlib, but we’ll prototype them as test-cases to see if they work at all and how lean/convenient/nice the resulting code is.
What are the goals of this serialisation framework? What is it’s raison d’etre? To be better/faster than Jackson? (imo I’d say Jackson is the main existing competitor so expect there are aspects you don’t like in Jackson)
Will it support any JVM bean (Java, Groovy, Scala etc)? The reason I ask is that I suspect many development efforts on the JVM are multi-language (and the existing serialisation frameworks support “beans” written in any JVM language).
The top-level goals are listed at the beginning of this thread: Kotlin Serialization
Answering your specific questions I can add here, that we don’t see any reason to spend our time to make a better/faster framework for JVM than Jackson/Gson. Our primary driving use-case is isomoprhic Kotlin, e.g. a common Kotlin code that works with the same semantics on all Kotlin backends (JVM, JS, Native). We don’t have Jackson on either JS nor Native, so there’s nothing be better/faster there.
Moreover, we don’t want to limit ourselves to any particular serialization format or even a family of serialization formats. We are not working in “JSON Information Set” (if you excuse me for using this term) like Jackson, but in “Kotlin Information Set”, e.g. we take Kotlin’s type system and present Kotlin’s objects and their elements to the library that is going to map the corresponding information set into whatever output format. Basically, Kotlin Serialization framework simply provides Kotlin’s object-traversal facility.
A very important use-case that we have is not directly related to serialization or even JSON for that matter. It is about loading Kotlin objects from databases and configuration files. E.g. our main goal is make it possible to do it all without reflection, since we don’t plan to support reflection on either Native or JS backends in the near future.
As for JVM beans, yes. JVM interop on JVM backend is a very important piece of Kotlin’s story and we do plan to support JVM beans in some way.
This is exactly what I would propose too 
. When you work with POJOs whose properties are set dynamically using reflection etc., then defining such POJOs in this way is quite annoying. I would summarize it in these 3 points:
- If property is marked as nullable and is not initialized explicitly, it will be initialized to null by default
- If property is a non-nullable numeric type and is not initialized explicitly, it will be initialized to 0 by default (same as in Java)
- If property is of any other (unknown) non-nullable type (class) and is not initialized explicitly, Kotlin could look if this class has an empty constructor, if it does, the property will be initialized using this empty constructor, otherwise a compile error will show up requesting explicit initialization
That might be quite helpful . Or another option would be to add “Initialize all properties with default initializers” functionality in IDEA 
, or is it already there?