I have created a Serialisation library for the JVM which I named Memento. It is based on a simple adapter system which makes it much more flexible than the Java-Serialization. It is in binary format and beats Java-Serialization for big objects in disc-space and performance by two times. Contributions are very welcome and I would be very happy when somebody could give me tips on how to make my explanation in the README better as I’m not a native English speaker.
If you are creating serialization library for kotlin, you should compare it not with java, but with koltin-serialization which will be part of the compiler from 1.3. I do not see advantage of using Memento over kotlin serialization in kotlin. Maybe someone could use it in java though, because kotlin-serialization, being a compiler plugin obviously could not be used from java for java classes.
The advantage of Memento over kotlin-serialization is that it allows more flexibility (explained in the README). I agree with you that not everybody needs this flexibility, but for my main-project for example I need a caching mechanism that holds Mementos in memory with a soft reference until they are garbage collected and then serialised.
What flexibility are you talking about? I do not see anything in that library, which is not offered by other libraries, such a Kotlin serialization or Jackson. I see several disadvantages compared to those:
- Third party classes cannot be serialized, as they are required to implement
Memorable - It uses a custom undocumented data format, rather than any standard format such as JSON or XML
- It uses a binary data format, which makes it incomprehensible to humans
- Unlike Kotlin serialization, it is not portable to other platforms than JVM
- I cannot quite tell, but it seems to depend on Kotlin features, so I am not sure it would be useful from other JVM languages
To be honest, I get the feeling that you used Java Serialization as your only baseline, and when you ran into a limitation with that, you created this library. The thing is, however, that Java Serialization is not the only option out there, nor is it the preferred serialization method in all cases. In most cases, using a library for serializing to standard formats such as JSON or XML is a better option.
Thank you for your (pretty harsh (
feedback.
I think your first and the last point are not quite right. You can register custom memento adapters for third party classes (see this section).
And which Kotlin-specific features are talking of in your last point? If you talk of the companion object, I made my implementation also accept static methods.
In the other points you are right except that I think that binary-formats also have advantages over human readable formats.
The point of Memento is not only serialisation but also a simplified mechanism of compressing objects in Mementos and caching these.
1 Like
Cool stuff! 
I’m not sure it matters if there’s some preferred serialization library to use over a newer library like this one. It all gets used the same way in the end (assuming the use of the library is properly isolated, #cleanArchitecture).
Doing new things is always good! Keep it up
I’ve had the best results from moshi-kotlin-codegen, which has the advantage of not requiring the enormous Kotlin reflection library. If there are use cases Moshi doesn’t cover you might consider contributing them there.
One point about the Kotlin serialization plugin. People seem to equate the formats built in to the library with the capability of the system. It is perfectly possible to write your own formats or to even create ones that do JSON… in a different way, perhaps delegating to the original where appropriate. For example, the caching feature is something that can be perfectly supported by a format.
The serialization plugin basically creates the code specific to the type to be serialized. The format gets the right callbacks and does the serialization. (I’ve written a format for XML). I would have to say that the current format is somewhat cumbersome and seriously underdocumented. The new proposed version in the KEEP is much better. The plugin can also have features that are hard to implement otherwise or much less elegant (like default values).
As an alternative for a when Java objects need to be handled, have a look at Kryo that also supports custom adapters. It can be made Kotlin compatible quite easily (you need to special-case Kotlin objects to retain single instances). It serialises literally anything, but does use reflection.