ArgumentMatchers#argThat does not work properly when executing GraalVM's NativeTest with the ProxyMockMaker plugin

[linghengqian]

• Since Add metadata for Mockito 4.8.1 oracle/graalvm-reachability-metadata#141 has verified that org.mockito.internal.creation.proxy.ProxyMockMaker can execute Mockito unit tests in Native Image, I am at Add support for io.etcd:jetcd-core:0.7.5 oracle/graalvm-reachability-metadata#170 does some additional validation work.

• Most of the unit tests related to org.mockito.internal.creation.proxy.ProxyMockMaker are normal, but there is a unit test that uses org.mockito.ArgumentMatchers#argThat is an exception, with the following stack. It looks like ArgumentMatchers#argThat is not working properly when executing GraalVM's NativeTest with the ProxyMockMaker plugin.

Failures (1):
  JUnit Jupiter:WatchUnitTest:testWatchOnSendingWatchCreateRequest()
    MethodSource [className = 'io.etcd.jetcd.impl.WatchUnitTest', methodName = 'testWatchOnSendingWatchCreateRequest', methodParameterTypes = '']
    => java.lang.NoSuchMethodError: Method 'matches(T)' not found in ArgumentMatcher: io.etcd.jetcd.impl.WatchUnitTest$$Lambda$a88e68baede6e66eff0f2a28b8835d22591864c6@7a3353ac !
 Please file a bug with this stack trace at: https://github.com/mockito/mockito/issues/new 
       org.mockito.internal.invocation.TypeSafeMatching.getArgumentTypeUncached(TypeSafeMatching.java:77)
       org.mockito.internal.invocation.TypeSafeMatching.lambda$getArgumentType$0(TypeSafeMatching.java:61)
       java.base@17.0.5/java.util.concurrent.ConcurrentHashMap.computeIfAbsent(ConcurrentHashMap.java:1708)
       org.mockito.internal.invocation.TypeSafeMatching.getArgumentType(TypeSafeMatching.java:60)
       org.mockito.internal.invocation.TypeSafeMatching.isCompatible(TypeSafeMatching.java:48)
       org.mockito.internal.invocation.TypeSafeMatching.apply(TypeSafeMatching.java:35)
       org.mockito.internal.invocation.MatcherApplicationStrategy.argsMatch(MatcherApplicationStrategy.java:94)
       org.mockito.internal.invocation.MatcherApplicationStrategy.forEachMatcherAndArgument(MatcherApplicationStrategy.java:74)
       org.mockito.internal.invocation.InvocationMatcher.argumentsMatch(InvocationMatcher.java:156)
       org.mockito.internal.invocation.InvocationMatcher.matches(InvocationMatcher.java:82)
       [...]

Test run finished after 8 ms
[         2 containers found      ]
[         0 containers skipped    ]
[         2 containers started    ]
[         0 containers aborted    ]
[         2 containers successful ]
[         0 containers failed     ]
[         1 tests found           ]
[         0 tests skipped         ]
[         1 tests started         ]
[         0 tests aborted         ]
[         0 tests successful      ]
[         1 tests failed          ]


FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':nativeTest'.
> Process 'command '/home/linghengqian/TwinklingLiftWorks/git/public/mockito-junit-platform-test/build/native/nativeTestCompile/mockito-junit-platform-test-tests'' finished with non-zero exit value 1

* Try:
> Run with --stacktrace option to get the stack trace.
> Run with --info or --debug option to get more log output.
> Run with --scan to get full insights.

* Get more help at https://help.gradle.org

BUILD FAILED in 2m 23s
8 actionable tasks: 8 executed

• I created a minimal reproducible unit test at https://github.com/linghengqian/mockito-junit-platform-test, which can be reproduced by following the steps below.

sudo apt install unzip zip curl sed -y
curl -s "https://get.sdkman.io" | bash
source "$HOME/.sdkman/bin/sdkman-init.sh"
sdk install java 22.3.r17-grl
sdk use java 22.3.r17-grl
gu install native-image
sudo apt-get install build-essential libz-dev zlib1g-dev -y

git clone git@github.com:linghengqian/mockito-junit-platform-test.git
cd ./mockito-junit-platform-test/
./gradlew -Pagent clean test
./gradlew metadataCopy --task test
./gradlew clean nativeTest

• I'm not quite sure if I should report it here, but StackInfo suggested I open a new issue at Mockito. The core code is very simple. More early investigations from Make ShardingSphere Proxy in GraalVM Native Image form available apache/shardingsphere#21347 and Some plan to write additional unit tests for the class library need GraalVM Reachability Metadata linghengqian/graalvm-trace-metadata-smoketest#1 .

@Test
    public void testWatchOnSendingWatchCreateRequest() {
        try (Watch.Watcher ignored = watchClient.watch(
                KEY,
                WatchOption.DEFAULT,
                Watch.listener(TestUtil::noOpWatchResponseConsumer))) {
            verify(this.requestStreamObserverMock, timeout(100).times(1)).onNext(argThat(hasCreateKey(KEY)));
        }
    }

check that

• The mockito message in the stacktrace have useful information, but it didn't help
• The problematic code (if that's possible) is copied here;
  Note that some configuration are impossible to mock via Mockito
• Provide versions (mockito / jdk / os / any other relevant information)
• Provide a Short, Self Contained, Correct (Compilable), Example of the issue
  (same as any question on stackoverflow.com)
• Read the contributing guide

[raphw]

It's not trivial to debug the native compilation, but I think that Graal has not added support for calling the matchers reflectively:

mockito/src/main/java/org/mockito/internal/invocation/TypeSafeMatching.java

Line 70 in 89698ba

Method[] methods = argumentMatcher.getClass().getMethods();

We are using this approach to extract the actual type of the otherwise generic matcher. Graal would need to add all of Mockito's matcher classes to its reflective metadata to support at least the built in matchers. But even then lambdas and custom matchers would fail.

@TimvdLippe Do you think we can skip the type-check on Graal? We would then simply need to call the matcher and consider a class-cast-exception as a "negative match". It's less pretty, but it would work at least.

[TimvdLippe]

I would prefer to not ship code just for Graal, if we can avoid it. That said, I am not familiar with how Graal does the method detection here, so if there is no other option, then yes let's do it.

[linghengqian]

• I somewhat suspect that this is related to The junit-native does not support org.junit.rules.ExpectedException. graalvm/native-build-tools#575 , I will verify the current issue in the next version of GraalVM Native Build Tools.