Does Kryo handle serialVersionUID mismatches?

113 views
Skip to first unread message

Mirko Swillus

unread,
Jul 18, 2018, 10:00:37 AM7/18/18
to kryonet-users
Hi everyone, 

short question: I just had a look at the serialized byte output of Kryo and found that the serialVersionUID of my classes is not part of the byte stream, so the comparison on the receiver end is generally not possible (to check if source and target class do match).

I googled a little but found no information about that serialVersionUID handling of Kryo, is there some documentation? Thanks, 

Mirko

Nate

unread,
Jul 18, 2018, 7:46:17 PM7/18/18
to kryone...@googlegroups.com
serialVersionUID is part of Java's built-in serialization. Kryo doesn't do anything with it at all. See the Kryo docs about compatibility for the various serializers.


--
You received this message because you are subscribed to the "kryonet-users" group.
http://groups.google.com/group/kryonet-users
---
You received this message because you are subscribed to the Google Groups "kryonet-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kryonet-users+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Mirko Swillus

unread,
Jul 19, 2018, 6:30:49 AM7/19/18
to kryonet-users
Hi Nate, 

thanks for that reply, very helpful. Can you give me a hint how we can manage that changed implementations in distributed environments are not causing runtime issues? I have to use Kryo because its part of the product, but I'd like to have a feature that is more or less comparable to checking for a serialVersionUID. Context: we're facing IncompatibleClassChangeErrors from time to time (obviously when accessing objects that were deserialized using Kryo).

Thanks for your help again, 
Mirko
To unsubscribe from this group and stop receiving emails from it, send an email to kryonet-user...@googlegroups.com.

Nate

unread,
Jul 19, 2018, 7:40:50 AM7/19/18
to kryone...@googlegroups.com
Don't use FieldSerializer, since it doesn't have any compatibility. I don't like the chunked encoding overhead of CompatibleSerializer. I prefer TaggedFieldSerializer, which means you must annotate the fields of your classes and cannot (ever!) remove fields. You can rename fields though. When deprecated fields are still read but not written. See the docs for details. If a class gets too different, you can register a new class and use a serializer that reads the old class and provides an instance of the new class, optionally setting any data from the old to the new. VersionedFieldSerializer is OK, but TaggedFieldSerializer gives you more options.

If performance is not important, you could use Java's built-in serialization through Kryo (see JavaSerializer).


To unsubscribe from this group and stop receiving emails from it, send an email to kryonet-users+unsubscribe@googlegroups.com.

Mirko Swillus

unread,
Jul 19, 2018, 8:17:57 AM7/19/18
to kryonet-users
Hi Nate, 

thanks for all the advices (very interesting for me as a serialization noob), we will have a look at it. Cheers, Mirko
Reply all
Reply to author
Forward
0 new messages