Allow androidx_test to use Mockito 2

[copybara-androidxtest]

Allow androidx_test to use Mockito 2

[googlebot]

We found a Contributor License Agreement for you (the sender of this pull request), but were unable to find agreements for all the commit author(s) or Co-authors. If you authored these, maybe you used a different email address in the git commits than was used to sign the CLA (login here to double check)? If these were authored by someone else, then they will need to sign a CLA as well, and confirm that they're okay with these being contributed to Google.
In order to pass this check, please resolve this problem and have the pull request author add another comment and the bot will run again. If the bot doesn't comment, it means it doesn't think anything has changed.

ℹ️ Googlers: Go here for more info.

[trietbui85]

Why don't we use static import for org.mockito.hamcrest.MockitoHamcrest.argThat to make code shorter?

[TimvdLippe]

This is the remnant of the upcoming migration to migrate away from MockitoHamcrest. If we don't differentiate between argThat invocations that take a Matcher and an ArgumentMatcher, we can't make future migrations. E.g. in this file, if you only only use Matcher, you can statically import. But if you also pass in ArgumentMatcher, you can't and you have to differentiate.

We took the conservative route of migrating to the verbose MockitoHamcrest.argThat to allow future migrations to simply import argThat if they were using an ArgumentMatcher.

[TWiStErRob]

Just for me to fully understand and learn:
If you import both MockitoHamcrest.argThat and ArgumentMatcher.argThat and overload resolution will decide which one is which.

(explicit, no conflicts)

import org.hamcrest.Matchers;
import org.mockito.ArgumentMatchers;
import org.mockito.hamcrest.MockitoHamcrest;
import org.mockito.internal.matchers.StartsWith;

when(mock.method(
    MockitoHamcrest.argThat(Matchers.startsWith("foo")),
    ArgumentMatchers.argThat(new StartsWith("foo"))
)).then...

vs.

(implicit, works w/ overload resolution)

import static org.hamcrest.Matchers.startsWith;
import static org.mockito.ArgumentMatchers.argThat;
import static org.mockito.hamcrest.MockitoHamcrest.argThat;
import org.mockito.internal.matchers.StartsWith;

when(mock.method(
    argThat(startsWith("foo")),
    argThat(new StartsWith("foo"))
)).then...

Is the problem that only looking at the stubbing setup in just the source code it's hard to know (in an automated way) which one is which, because of the double import?

[TimvdLippe]

If I am not mistaken, that is disallowed by the specification:

If a compilation unit contains both a single-static-import declaration that imports a type whose simple name is n, and a single-type-import declaration (§7.5.1) that imports a type whose simple name is n, a compile-time error occurs, unless the two types are the same type, in which case the duplicate declaration is ignored.

(https://docs.oracle.com/javase/specs/jls/se11/html/jls-7.html#jls-7.5.3)

Since we have to import two different static methods from two different classes with two different signatures, that would not compile. E.g. for now it would work, as both methods accept Matcher, but once we make the switch, ArgumentMatchers.argThat will take an ArgumentMatcher, whereas MockitoHamcrest.argThat will take a Matcher.

[TimvdLippe]

(FYI I am speaking in terms of the state of the internal repository. Once we are all on Mockito 2, these statements might no longer be true)

[TWiStErRob]

Aaaah, Mockito 2, that's where I tried, no error. Thanks for coming back to me.

You're right about the signature change, I forgot about that since we migrated.
https://static.javadoc.io/org.mockito/mockito-core/1.10.19/org/mockito/Matchers.html#argThat(org.hamcrest.Matcher)
https://static.javadoc.io/org.mockito/mockito-core/2.25.1/org/mockito/ArgumentMatchers.html#argThat-org.mockito.ArgumentMatcher-
https://static.javadoc.io/org.mockito/mockito-core/2.25.1/org/mockito/hamcrest/MockitoHamcrest.html#argThat-org.hamcrest.Matcher-
Note MockitoHamcrest is a Mocktio 2.1+ class.

---

Re JLS, that clause of 7.5.3 talks about "type whose simple name" (type as opposed to member/method/field), so it's referring to this:

import java.lang.Thread.State;
import static java.lang.Thread.State; // valid according to last sentence
import static javafx.concurrent.Worker.State; // compile-time error according to first sentence

Importing same-name methods from different types with same/different signatures is fine. It's the usage that'll blow up when it tries to do the overload resolution (if there are multiple with same signature). Having two methods in different type with same name, different signature behaves similarly to two methods in same type with same name, different signature.

[TimvdLippe]

I am unable to inspect the build results on this PR, but the presubmit internally was passing.

[TimvdLippe]

Even though I can't inspect the build results, I think this is failing because of not having linkedin/dexmaker#138 released.

[brettchabot]

note the github CI is currently broken at head, I'm working on it.

[TimvdLippe]

All right. Let me know when it is fixed so I can retrigger the CI build 😄