java.time does not appear to serialize/deserialize properly

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

java.time does not appear to serialize/deserialize properly

Geoff Groos
Hey guys,

I’m wondering what you guys think of XStream + the new (java 1.8) java.time library.

I’ve started replacing joda.time uses with java.time ones (as encouraged by the Joda time guys themselves) and I only noticed when I ran my persistence tests that anything causing XStream to touch a java.time.Instant instance would fail.

A simple test to reproduce:

    private static class ClassWithTimestamp{
        public final Instant timestamp = Instant.now();
    }

    @Test
    public void when_serializing_a_timestamp_xstream_should_have_no_trouble(){
        //setup
        XStream vanillaXStream = new XStream();
        ClassWithTimestamp originalInstance = new ClassWithTimestamp();

        //act
        String serialized = vanillaXStream.toXML(originalInstance);
        ClassWithTimestamp deserialized = (ClassWithTimestamp) vanillaXStream.fromXML(serialized);

        //assert
        assertThat(deserialized.timestamp).isEqualTo(originalInstance.timestamp);
    }


Thoughts?

I’m implementing custom converters now, and since java.time is so much more interoperable with the ISO 8601 spec than that worse-than-useless java.util.Date stuff, I’m thinking I’ll register these as immutable and have them serialize and deserialize to nice ISO strings.

I’d be honored if I could push that stuff upstream to you guys!

-Geoff

Sent from Windows Mail

Reply | Threaded
Open this post in threaded view
|

Re: java.time does not appear to serialize/deserialize properly

Jörg Schaible-4
Hi Geoff,

Geoff Groos wrote:

> Hey guys,
>
> I’m wondering what you guys think of XStream + the new (java 1.8)
> java.time library.

Someone has to start :-)

> I’ve started replacing joda.time uses with java.time ones (as encouraged
> by the Joda time guys themselves) and I only noticed when I ran my
> persistence tests that anything causing XStream to touch a
> java.time.Instant instance would fail.
>
> A simple test to reproduce:
>
>     private static class ClassWithTimestamp{
>         public final Instant timestamp = Instant.now();
>     }
>
>     @Test
>     public void
>     when_serializing_a_timestamp_xstream_should_have_no_trouble(){
>         //setup
>         XStream vanillaXStream = new XStream();
>         ClassWithTimestamp originalInstance = new ClassWithTimestamp();
>
>         //act
>         String serialized = vanillaXStream.toXML(originalInstance);
>         ClassWithTimestamp deserialized = (ClassWithTimestamp)
>         vanillaXStream.fromXML(serialized);
>
>         //assert
>        
assertThat(deserialized.timestamp).isEqualTo(originalInstance.timestamp);
>     }
>
>
> Thoughts?

Well, actually XStream should have been able to marshal/unmarshal this, but
I'll have a look.
 
> I’m implementing custom converters now, and since java.time is so much
> more interoperable with the ISO 8601 spec than that worse-than-useless
> java.util.Date stuff, I’m thinking I’ll register these as immutable and
> have them serialize and deserialize to nice ISO strings.

That would be definitely the best approach.

> I’d be honored if I could push that stuff upstream to you guys!

A very welcome addition to XStream, it would be nice to get such a
contribution!

Cheers,
Jörg

Note, XStream is currently in the transition from Codehaus to Github. If
you're ready to contribute, please give a note here that we may point you to
the proper place.


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email