this library needs new Maintainers (Serialization without annotation!)

[sdfgsdfgd]

Hi

https://github.com/Kotlin/kotlinx.serialization/issues/1808

it seems this library is maintained by the wrong individuals and it needs urgent attention

It has been 3 years since the community started insisting on this MUCH REQUIRED functionality, with frequent back and forth between us and the maintainer. A maintainer shouldn't be able to push back against the community this much. We are denied a brighter future with concise, minimal API and we are given strawman arguments just because lazy maintainers dont want to dive in and add this long awaited feature that Gson() and many others have taken care of.

It should be unacceptable

This library has a special place in our hearts for being the future favourite choice for android and compose multi platform projects. At the bare minimum it has to provide the core functionalities that we are used to, with Gson(), moshi and many others. Serialization without having to annotate thousands of auto generated data classes is definitely one of them.

[JakeWharton]

Obviously your request is ridiculous on face value, but

At the bare minimum it has to provide the core functionalities that we are used to, with Gson(), moshi and many others. Serialization without having to annotate thousands of auto generated data classes is definitely one of them.

Ignoring that a library obviously does not have to provide something another library provides simply because that other library provides it, I can chime in here as a maintainer of Gson for a few years and one of the creators of Moshi.

Using Moshi and Gson as an example harms your argument. Gson will happily serialize the implementation details of java.io.File whereas Moshi will not. One of the values of Moshi was to prevent serialization of framework types whose implementation you do not control. This was for Java types, where reflection facilities provided great power.

When Kotlin came along, Moshi actually went even more strict and refused to serialize a Kotlin type unless it was annotated with @Json. This was done because we needed to use the heavy kotlin.reflect.full package to properly honor the semantics of Kotlin classes, or we had to do codegen to provide a model which represented the already-parsed semantics.

All of that to say, Moshi refuses to serialize a Kotlin type unless it's annotated so it's not really a candidate for your argument.

[sdfgsdfgd]

Thank you for blessing the thread with your presence Jake. @JakeWharton I will try this one more time.

Let's forget about moshi and focus on better arguments, what is your take on :

Ease of Integration

Allowing serialization without annotations would make kotlinx.serialization a more straightforward drop-in replacement for Gson or Jackson, particularly for data classes.

Flexibility

Implicit serialization can serialize third-party classes that can't be annotated, offering greater flexibility in handling external models

Developer Expectations

Given the prevalence of libraries like Gson and Jackson, many developers expect serialization libraries to handle classes without requiring annotations.

What is your take on these heavy arguments ? How do you push back against all of this? Are you going to say "Explicit annotations can be a safeguard against unintentionally serializing sensitive data" ? This is a weak argument if proper data handling practices are in place, which is what your maintainers are saying, they keep saying it's vulnerability, vulnerability, as if they just discovered the software security like it's 1995

Also, good point about Gson()'s unwanted side effects like serializing impl details of File.

However...

• Developer Productivity: One of the primary goals of any library is to improve developer productivity. Requiring fewer steps for common tasks, like serialization, directly contributes to faster development and simpler codebases. In many cases, the ease of use provided by a library like Gson outweighs the risks associated with less control.

• Responsibility Shift: While Gson may serialize implementation details unintentionally, it could be argued that it's the responsibility of the developer to understand and manage what is being serialized. Developers should be aware of the structure and content of the classes they are serializing. Proper documentation and guidelines can mitigate risks associated with unintentional serialization.

Conclusion: A middle-ground approach could be to have a default behavior that allows easy serialization (like Gson), but provide mechanisms to strictly control or prevent serialization of certain fields or classes when needed. This approach offers flexibility while still giving developers the tools to avoid potential issues.

[JakeWharton]

How do you push back against all of this?

All of those arguments are mostly irrelevant when there's no technical means to sufficiently introspect the metadata of a class to perform accurate serialization on all platforms that Kotlin supports. Through what mechanism are you discovering the list of candidate properties from a class and the type of each on JS, native, and WASM? On the JVM we've already established that the kotlin.reflect.full package can be used to parse the protocol buffers embedded in the @kotlin.Metadata annotation which provides everything needed, but no other platform provides such capability today. This is not a limitation of this serialization library, but fundamentally of the Kotlin language.

[qwwdfsad]

Thanks Jake for chiming in.

I am not sure a further technical discussion is possible in this thread; starting it by harassing my team members instead of providing sufficient technical or non-technical concerns and arguments does not really work, as well as having an uncompromising stance about what should and shouldn't be done and why.

If you have any specific concerns about potential unacceptable behaviour, you can reach me in public Slack as @Vsevolod Tolstopyatov [JB] or refer to our Code of Conduct. For a technical discussion, I suggest starting a different GH issue in a less heated manner; https://github.com/Kotlin/kotlinx.serialization/issues/1247 is a decent example of how it can be done

[pdvrieze]

This appears to be fundamentally an issue due to the fundamental design of the library as a statically resolved serialization library. The request seems to want serialization that works in the way many dynamic libraries/frameworks work. Looking at the library I don't see anything that stops someone to write a custom serializer that is dynamic, and is then used by formats as if it was a generated serializer, but if there were some aspects in the design that could make this easier it may be reasonable to accommodate those needed changes (if not changing the design of kotlinx.serialization).

[sdfgsdfgd]

@qwwdfsad sorry if the language was a bit too ambitious, I do not mean to be rude at all, I'm channeling the frustration of our community and we didn't know the blocker was due to something fundamental such as limitations of introspection on specific targets. We have to get to a milestone, and we have to get there for the future generations. We have very similar nicknames too buddy

@pdvrieze

Looking at the library I don't see anything that stops someone to write a custom serializer that is dynamic, and is then used by formats as if it was a generated serializer, but if there were some aspects in the design that could make this easier it may be reasonable to accommodate those needed changes (if not changing the design of kotlinx.serialization)

well said. If it's not IMPOSSIBLE to achieve this, I would be more than happy to help out and bring more people in to contribute. Let's slam issues on kotlin compiler, design of language, and make all necessary changes to support the dynamic introspection across Web and Desktop targets as well at least, if we can do this somehow.

I know people that would love to join the effort, I'd be one of them as a startup. Let's not get caught up with words and continue with the current team, although you guys are a bit lazy and full of excuses, I have a feeling we can do it.

If this can be achieved this will carry the framework, the compose multiplatform itself and Kotlin as a language, to another realm. It's the small additions like these that will set a bright future for compose multiplatforming.

@JakeWharton Can we propose and work on new Kotlin Language Enhancement Proposals (KLEPs) focused on enhancing introspection capabilities ?

in the meantime we can begin with platforms that already support the required introspection capabilities (like the JVM). This approach provides immediate benefits where feasible and sets a foundation for future expansion.

[JakeWharton]

Please keep me out of your efforts. I have no interest in helping you based on the way you are conducting yourself.

[sdfgsdfgd]

OK

couldn't care less, this library can go to hell then 👍 I wont bother any of you again. If you were a bit selfless instead of getting caught up in politeness or how people conduct themselves you would take some criticism and work with people for once. Not surprising though, you're a pop star of the kotlin world, you care about your personal reputation

[GreemDev]

You have an Imperial Japan flag as your avatar. We don't want you. Good riddance.