ArrayComparisonFailure serialization incompatibility fix:

[aishahalim]

Add back field fCause, initialize and use in the constructor (via initCause()) to avoid npe and unused field warnings, respectively
Issue #1178, #976

[marcphilipp]

Thanks for the pull request! On second thought I think we need to do a little more.

As you have verified in #1178 (comment) this will ensure that pre 4.12 versions can consume post 4.12 versions' ArrayComparisonFailures. However, this does not hold the other way around. We should override getCause() similar to this:

public synchronized Throwable getCause() {
    return super.getCause() == null ? fCause : super.getCause();
}

I agree that this is hard to test. However, I think the following should be fairly easy doable (@kcooney has done the same for Result in f6149a9):

1. Create a ArrayComparisonFailure using 4.11 and serialize it into a file.
2. Put the file into src/test/resources and add a test that reads it, deserializes it and checks the resulting ArrayComparisonFailure

Do the same for 4.12.

@aishahalim Please let me know if you're okay with doing that.

[aishahalim]

However, this does not hold the other way around.

Yikes, yes I see it now.

Thanks for pointing out how to construct that test! On it!

[aishahalim]

Hey Marc!

I've update this pullrequest with another commit. Your test strategy description, when implemented in the test, very apparently caught the forward incompatibility problem with getCause() not falling back to fCause.

I threw in a description in the test to explain what it's interacting with (since super wordy variablenames don't fill in the blanks around all the "serializing to a file setup") and why.

What do you think about it so far?

I didn't mull over it long enough, but I don't see how I could test the other way, where I have a current version of an exception deserializing with an older version of the class. Is this implemented in f6149a9? I threw a breakpoint in when running ResultTest and still didn't see anything that tried to serialize to a special version of a class, unless you were referring to the fixed runtime sub class -- i.e. subclassing ArrayComparisonFailure to behave like the previous versions', then testing compatibility with the current version's instance of the failure?

Apologies for all these questions.

[marcphilipp]

Looks good to me, you did exactly what I had in mind! 👍

@junit-team/junit-committers What do you think, is this good to merge?

[PeterWippermann]

Any updates on this?

[aishahalim]

^ It might be a bit of a hefty changeset for a not-at-all-critical bug, so, understandably, second review might take longer.

Let me know if I should split out any functional bits in separate commits for reviewing succinctness or whatnot.

[marcphilipp]

@junit-team/junit-committers I'd like a second opinion on this. Can one of you guys please have a look?

[kcooney]

LGTM. @marcphilipp was there something specific you were concerned about?

[marcphilipp]

was there something specific you were concerned about?

@kcooney Basically I just wanted to have another pair of eyes look at it to decrease the probability that we've overlooked something. :-)

[marcphilipp]

@aishahalim Thanks again! 👍 Please add a description of this fix to the draft of the release notes.

[aishahalim]

Thanks @marcphilipp :D

Added the description here: https://github.com/junit-team/junit4/wiki/4.13-Release-Notes#pull-request-1315-assertarrayequals-shouldnt-throw-an-npe-when-test-suites-are-compiledrun-across-versions-of-junit

Thanks a bunch all!

[PeterWippermann]

Well done, @aishahalim! 👍