Skip to content

1.x: distinctUntilChanged change erroneous behavior #4276

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 1 commit into from
Closed

1.x: distinctUntilChanged change erroneous behavior #4276

wants to merge 1 commit into from

Conversation

godardt
Copy link

@godardt godardt commented Aug 3, 2016

📘 PR summary

Fix behavior change of distinctUntilChanged introduced in the version 1.1.7 of RxJava

Related to: #4034

@godardt godardt changed the title Change compared keys 1.x: distinctUntilChanged change erroneous behavior Aug 3, 2016
@@ -62,7 +62,7 @@ public OperatorDistinctUntilChanged(Func2<? super U, ? super U, Boolean> compara

@Override
public Boolean call(U t1, U t2) {
return (t1 == t2 || (t1 != null && t1.equals(t2)));
return (t1 == t2 || (t2 != null && t2.equals(t1)));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please add a test case that fails without fix and passed with it

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

An example:
Object t1 and t2 are of the same type and contains an object x1.
Object x1 is null in t1 and is not null in t2
Object t1 and t2 override equals which in turn calls the equals of x1.
A NullpointerException is thrown from t1 but not from t2.

This is a basic example but what I want to say is that applying equals on t1 does not means that it will result the same the other way around.
That's the type of behavior changes which should be fixed on the user side of the rxjava lib but which can create confusion and can be avoided.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The current comparison is completely legal, same as Java 7's Objects.equals(). Why did you swap the variables? Implementation of equals should be symmetric: a.equals(b) == b.equals(a).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's a broken equals implementation and not this library's problem.

@artem-zinnatullin
Copy link
Contributor

Omg, I'm from phone at the moment, but it looks very critical, right?

As far as I see it won't compare old value with new if old is null

@codecov-io
Copy link

Current coverage is 84.43% (diff: 100%)

Merging #4276 into 1.x will decrease coverage by 0.06%

@@                1.x      #4276   diff @@
==========================================
  Files           268        268          
  Lines         17476      17476          
  Methods           0          0          
  Messages          0          0          
  Branches       2664       2664          
==========================================
- Hits          14768      14756    -12   
- Misses         1854       1861     +7   
- Partials        854        859     +5   

Powered by Codecov. Last update 0f23a15...87b3255

@artem-zinnatullin
Copy link
Contributor

ok, I'm with computer now and I don't see what's the problem with previous code. Can you please explain?

@akarnokd
Copy link
Member

akarnokd commented Aug 3, 2016

@artem-zinnatullin My guess is that he has a bug in his equals implementation and wants to change the library for a workaround.

@godardt
Copy link
Author

godardt commented Aug 3, 2016

@akarnokd Yes it's the case, it permitted me to pinpoint a bug on my side and I fixed it. But I though that if we could avoid people this behavior change it would be great

@godardt godardt closed this Aug 3, 2016
@JakeWharton
Copy link
Contributor

After this change, all you need to do is reverse t1 and t2 to get the same failure again.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants