I don't like that this makes it extremely easy to ...

# stdlib

[jw]

I don't like that this makes it extremely easy to use the worst possible serialization format

[elizarov]

@Fleshgrinder These kind of extensions are extremely domain-special (like exceeding minority of Kotlin users would benefit from them) and, a the same, time they are so easy to add in your own project if you need them.

[elizarov]

@Fleshgrinder Just FYI, ObjectOutputStream is extremely expensive to create, so you’d never write a code like that in an actual enterprise project. In the enterprise I’ve worked for we had our own highly domain-specific wrapper and a set of utilites on top of OOS to make it memory-efficient and fast.

[Fleshgrinder]

The problem is that there are not many alternatives available. We have kotlin-x serialization but JSON is even more inefficient and Protobuf requires tons of annotations. I understand that the built in Java serialization might not be the best but it's the de facto standard for serialization in the JVM world.

That being said, I'd be open to an alternative solution that serializes to something else (potentially Kotlin cross platform) since my question is less about Java's serialization format in particular than about a readily available way of turning objects into `ByteArray`s and back to objects.

And obviously the general question how one should approach ideas but I guess I was right by posting here. 🙂

[elizarov]

Eventually, we plan to support some kind of efficient binary format in kotlinx.serialization

[Fleshgrinder]

Well, that one could be the one that is provided via such extension methods then. 🙂

The problem with serialization formats out there in the wild is that they always introduce new problems (e.g. no update to JDK9/10, …) or require one to write schemas (Protobuf, Avro, …) so having something that simply works out of the box is imho really important.

[gildor]

no update to JDK9/10

What do you mean?

[Fleshgrinder]

Protobuf and Protostuff for instance have problems with anything newer than JDK8. FST seems to work but ends up with some reflection exception in anything newer than JDK8.

[Vsevolod Tolstopyatov [JB]]

Protobuf requires tons of annotations

…

or require one to write schema

We’re going to fix both issues in kotlinx.serialization for Protobuf. Data classes will get first-class support without additional annotations (expect for specific optionality etc.) and it will be possible to generate schema from class

[Fleshgrinder]

Both sounds good. 🙂

[wakingrufus]

isn't Serializable being removed from newer versions of JDK anyway?