gaob13 / kryo

Automatically exported from code.google.com/p/kryo
BSD 3-Clause "New" or "Revised" License
0 stars 0 forks source link

Serializing fails, when a Generic is set #92

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago
With gson 2.2.2 google introduced a StringMap<V> which extends 
AbstractMap<String, V>. Kryo seems to assume the wrong number of generics for 
this class. 

The error occured with serializing a JsonObject of JsonObjects.

Have a look at the discussion here: 
https://groups.google.com/forum/?fromgroups=#!topic/kryo-users/GJWr6DB2cco

Original issue reported on code.google.com by mgledi@gmail.com on 4 Oct 2012 at 12:13

GoogleCodeExporter commented 8 years ago
Hi,

I think I have a solution for it. 

I created a code that properly derives which concrete classes are used for 
which generic type arguments. I added support for it into MapSerializer and 
CollectionSerializer. Seems to work fine for me. And it produces smaller 
serialized representations if it can automatically derive that types of keys, 
values or elements have a concrete final type. 
For example, if you have a class like this:

public class StringMap extends HashMap<String, String> {
}

When you serialize object of this class, no class information will be written 
for keys and values. Only the string values.

@Nate: Once you have time and mood to review new patches, please let me know, 
and I'll submit a patch for your review.

Original comment by romixlev on 12 Oct 2012 at 11:47

GoogleCodeExporter commented 8 years ago
Please find attached a patch for this problem. Seems to work for me.

Original comment by romixlev on 24 Oct 2012 at 10:04

Attachments:

GoogleCodeExporter commented 8 years ago
The patch seems to work fine, when using the always same constelation of 
generics for one class (e.g. Map), but fails when another combination of 
generics occurs. This is indicated by the JUnitTests delivered with Kryo. One 
of my coworkes fixed it, using your patch. Now, all JUnitTests are working 
correctly.

Original comment by mgledi@gmail.com on 15 Nov 2012 at 5:11