CompatibleSerializer deserializes wrongly if subclass has the same field as super class

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Run the code attached.
   jvm arg:  -Djava.io.tmpdir=<tempdir to stored the output file>

   //For default FieldSerializer
   test.withDefault(); 

   //For CompatibleFieldSerializer
   test.withCompatibleFieldSerializer;

2.  If the file is not there it will serialize a sample object to a file and 
save it to tempdir.
    If the file has already existed, the program will deserialize it.

3.

What is the expected output? What do you see instead?

//Output with default FieldSerializer: 
class[class 
com.scb.saturn.services.position.NewKryoTest$ChildModel];field1[f1];field2[f2];l
ongField[25];

//Output with CompatibleFieldSerializer:
class[class 
com.scb.saturn.services.position.NewKryoTest$ChildModel];field1[f1];field2[f2];l
ongField[0];

Expected the same output from both FieldSerializer and CompatibleFieldSerializer

What version of the Kryo are you using?
1.04

Please provide any additional information below.

Original issue reported on code.google.com by thin...@gmail.com on 4 May 2011 at 7:33

Attachments:

• NewKryoTest.java

[GoogleCodeExporter]

Attached is a version of the test that works with Kryo v2, is simpler, and 
doesn't have needless dependencies on spring and commons logging.

CompatibleFieldSerializer only writes the field names as the schema. To support 
a class hierarchy where a super type has the same field name as a subclass, we 
should probably write the declaring class along with the field name. This is 
quite a lot more information, which is unfortunate because this scenario is 
relatively rare. A flag could be written indicating if a field is stored as 
only a name or a class and name.

Original comment by nathan.s...@gmail.com on 26 Apr 2012 at 2:19

• Changed state: Accepted

Attachments:

• SameFieldNameTest.java

[GoogleCodeExporter]

Going to call this one a feature. ;) Fixing it isn't done easily and negatively 
effects the more common usage where this isn't an issue. I will update the 
javadocs to warn about this scenario.

Original comment by nathan.s...@gmail.com on 23 May 2012 at 10:50

• Changed state: WontFix