Nov11 / kryo

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

Incorrect (de)serialization of java.util.Date #23

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. Make a new Kryo object and register java.util.Date class.
2. Make a new Date object and serialize it.
3. Deserialize the Date object.

What is the expected output? What do you see instead?
The original date object and the deserialized one should be identical.

What version of the Kryo are you using?
1.01

Quick google'ing on this problem reveals a related note: 
http://stackoverflow.com/questions/2725233/kryo-serialization-library-is-it-used
-in-production

The workaroud provided there is to override the Date serializer:
[code]
kryo.register(Date.class, 
  new SimpleSerializer<Date>() {
   @Override public void write (ByteBuffer b, Date d) { b.putLong(d.getTime()); }
   @Override public Date read (ByteBuffer b) { return new Date(b.getLong()); }
  });
[/code]

I attached a unit test to reproduce the problem. It also contains the 
workaround code.

Original issue reported on code.google.com by vincas.m...@gmail.com on 3 Aug 2010 at 11:48

Attachments:

GoogleCodeExporter commented 9 years ago
Thanks for the nice bug report. If no serializer is specified, FieldSerializer 
is used. Because the private java.util.Date fields are all transient, nothing 
is serialized -- you always get back "now". Kryo comes with a DateSerializer 
that is slightly more efficient than the one you posted. See this thread for 
more information:
http://groups.google.com/group/kryo-users/browse_thread/thread/91969c6f48a45bdf/

Original comment by nathan.s...@gmail.com on 4 Aug 2010 at 12:21