Java 8 Date types

[bachi76]

I've just noticed that with the new java 8 date types (at least LocalDate), diff displays its inner properties, not like with the old Date class:

// new java 8 LocalDateTime
Property at path '/managedCare/validFrom/dayOfYear' has changed from [ 1 ] to [ 335 ]
Property at path '/managedCare/validFrom/hour' has been added => [ 14 ]
Property at path '/managedCare/validFrom/minute' has been added => [ 10 ]
Property at path '/managedCare/validFrom/month' has changed from [ JANUARY ] to [ DECEMBER ]
Property at path '/managedCare/validFrom/monthValue' has changed from [ 1 ] to [ 12 ]
Property at path '/managedCare/validFrom/nano' has been added => [ 827000000 ]
Property at path '/managedCare/validFrom/second' has been added => [ 50 ]
Property at path '/managedCare/validFrom/year' has changed from [ 2001 ] to [ 2014 ]

// old java.util.Date:
Property at path '/testdate' has been added => [ Mon Dec 01 14:10:50 CET 2014 ]

Would be great to be able to work with the new date types.

Thanks a lot for the lib! Martin

[SQiShER]

Thanks for pointing that out! This is actually a little bit tricky, but let me first give you a workaround: you can add the LocalDateTime class as equals-only type, to make it behave like the old java.util.Date. You can do that by configuring the ObjectDifferBuilder like so:

ObjectDiffer objectDiffer = ObjectDifferBuilder
    .startBuilding()
    .comparison().ofType(LocalDateTime.class).toUseEqualsMethod()
    .and().build();

This way LocalDateTime objects will only be compared via equals() method and not by comparing its properties. Let me know if this helps.

The tricky bit about making this the default behavior is that the library is designed to be compatible with Java 5, so we can't use Java 8 classes. Not even for such a simple check. A workaround would be to compare the class name as String, but such a mechanism is not in place and it doesn't feel right to me. Another possible solution would be to provide different releases for the different JDKs. But that adds a lot of complexity to the build (and the support). Too much complexity for right now. Probably the best solution would be a Java 8 wrapper, that uses the core library but provides a modern Java 8 API with streams, filters, closures, etc. and provides some sane defaults for new classes. But before I can even think about starting with that, there are some more pressing issues like diffing of ordered collections and arrays.

I hope for now the quickfix is good enough for you. :smiley:

Cheers Daniel

[bachi76]

Hi Daniel,

Thanks for the suggested fix, it works fine! As for java 8 dates vs ordered list priority, my 2 cents would be that everyone that uses java 8 and really needs object differ will most probably have these date types and thus stumble over this. And the adoption rate's high (and Oracle discourages the usage of the old date types in java 8). So - maybe at least adding that hint to the docs will save you from some upcoming support work :-).

Thanks again - Martin

[SQiShER]

Yup, you are right, documenting it definitely makes sense.