0

I've used javers in a different part of our app. Now I'm adding it to another, and am getting an IllegalArgumentException: argument should not be null. But I have verified (by serializing the objects and logging them) that the 2 objects are NOT null when passed to the compare() method.

Also, this only happens within a unit test run via Mockito. I assume there's a property of the objects that are passed in that is null, and that's what's creating the error. But isn't a null property a valid comparison for javers to detect?

I am using javers version 1.1.

Here's a snippet of my code:

private static final Javers javers = JaversBuilder.javers().build();
Diff difference = javers.compare(object1, object2);

Here's the stack trace:

java.lang.IllegalArgumentException: argument should not be null
    at org.javers.common.validation.Validate.argumentIsNotNull(Validate.java:16)
    at org.javers.common.validation.Validate.argumentIsNotNull(Validate.java:24)
    at org.javers.common.validation.Validate.argumentsAreNotNull(Validate.java:32)
    at org.javers.core.metamodel.type.SetType.map(SetType.java:21)
    at org.javers.core.diff.appenders.SetChangeAppender.calculateEntryChanges(SetChangeAppender.java:63)
    at org.javers.core.diff.appenders.SetChangeAppender.calculateChanges(SetChangeAppender.java:89)
    at org.javers.core.diff.appenders.SetChangeAppender.calculateChanges(SetChangeAppender.java:20)
    at org.javers.core.diff.DiffFactory.appendChanges(DiffFactory.java:142)
    at org.javers.core.diff.DiffFactory.appendPropertyChanges(DiffFactory.java:132)
    at org.javers.core.diff.DiffFactory.createAndAppendChanges(DiffFactory.java:114)
    at org.javers.core.diff.DiffFactory.create(DiffFactory.java:65)
    at org.javers.core.diff.DiffFactory.compare(DiffFactory.java:58)
    at org.javers.core.JaversCore.compare(JaversCore.java:75)
janisz
  • 6,292
  • 4
  • 37
  • 70
user26270
  • 6,904
  • 13
  • 62
  • 94
  • http://grepcode.com/file/repo1.maven.org/maven2/org.javers/javers-core/1.0.6/org/javers/common/validation/Validate.java. Does this help? First hit on google. – Chetan Kinger May 21 '15 at 17:10
  • This could just be a bug in javers. My next step would be to trace through the javers code to see if you can find where it's going wrong; otherwise the javers github page (https://github.com/javers/javers) has a link for reporting issues... at the very least failing the not-null requirement for that `SetType.map()` call should be caught and reacted to somewhere before it bubbles back up to the compare of two non-null objects. – Gus May 21 '15 at 17:21
  • I would love to step through it. Unfortunately I've got a bug in my IntelliJ setup right now that prevents me from debugging anything. Got another SO question on that. – user26270 May 21 '15 at 19:33
  • You're not using [`RETURNS_DEEP_STUBS`](http://site.mockito.org/mockito/docs/current/org/mockito/internal/stubbing/defaultanswers/ReturnsDeepStubs.html), right? Mockito's default behavior is to [return an empty Set for Set-type methods](https://github.com/bryceguo/mockito/blob/master/src/org/mockito/internal/stubbing/defaultanswers/ReturnsEmptyValues.java#L83). As a side note, passing a mocked-by-reflection object into a compare-by-reflection comparison framework seems fairly fragile to begin with, and may not test what you want it to test. – Jeff Bowman May 21 '15 at 19:43
  • No idea what RETURNS_DEEP_STUBS is. But I think the objects being compared are not mocked. They are kind of the 'main' objects in the service that's being tested, so we build them and pass them in. One of them is returned from a mocked storage service, but I don't know the internals of mockito, so I suppose that object could be mocked. But I still think the compared objects are valid because doesn't GsonSerializer use reflection as well? That's what I'm using to log the objects before I compare them, to make sure they are not null and data is valid. – user26270 May 21 '15 at 21:14
  • Fixed with a new version of javers. I was using 1.10. Switched to 1.2.1 and that fixed it. – user26270 May 22 '15 at 03:08
  • Glad it's fixed! Consider promoting your comment above to a self-answer you accept, so it can help anyone else who has this error. – Jeff Bowman May 22 '15 at 16:45

2 Answers2

0

Which Javers version are you using? I think I have fixed this NPE in 1.2.0. Try latest Jvers version, see http://javers.org

Bartek Walacik
  • 3,386
  • 1
  • 9
  • 14
0

I updated to version 1.2.1 and that fixed this problem.

user26270
  • 6,904
  • 13
  • 62
  • 94