问题描述
我正在努力将一个项目从java 7迁移到8，并且在Mockito中遇到编译错误当我很难跟踪时：
I'm working on migrating a project from java 7 to 8, and have gotten a compilation error in a Mockito "when" case I'm having a hard time tracking down:
when(queryRunner.query(any(String.class), any(ResultSetHandler.class), anyVararg())).thenReturn(mockedWordResultList);
给我一个编译错误：
gives me a compilation error of:
java: reference to query is ambiguous both method
<T>query(java.lang.String,java.lang.Object,org.apache.commons.dbutils.ResultSetHandler<T>)
in org.apache.commons.dbutils.QueryRunner and method
<T>query(java.lang.String,org.apache.commons.dbutils.ResultSetHandler<T>,java.lang.Object...)
in org.apache.commons.dbutils.QueryRunner match
此错误发生在构建1.8.0-b128中，但不会发生在1.7.0_45中。我正在使用mockito 1.9.5。
This error happens in build 1.8.0-b128, but doesn't happen in 1.7.0_45. I'm using mockito 1.9.5.
在java 8中使用 anyVarArg（）参数匹配的正确方法是什么？
What's the correct way to use anyVarArg() argument matching in java 8?
推荐答案
问题是类型推断已得到改进。 anyVararg（）是一种通用方法，但您在嵌套方法调用中使用它。在Java 8之前，类型推断的局限性迫使处理方法< T> T anyVararg（）喜欢< Object>对象anyVararg（）作为参数放置到另一个方法调用而不插入显式类型参数。
The problem is that the type inference has been improved. anyVararg() is a generic method but you are using it in a nested method invocation. Before Java 8 the limitations of the type inference forced treating the method <T> T anyVararg() like <Object> Object anyVararg() when placed as an argument to another method invocation without inserting explicit type arguments.
所以只有查询（String，ResultSetHandler，Object ...）匹配，因为第三个参数被视为类型为 Object 。
So only query(String, ResultSetHandler, Object...) matched as the third argument was treated as being of type Object.
但现在使用Java 8类型推断可以使用嵌套方法调用。因为< T> T anyVararg（）类型参数< T> 可以只是任何，它可以是 ResultSetHandler 。所以查询（String，Object，ResultSetHandler）现在也是一个匹配候选者。
But now with Java 8 type inference works with nested method calls. Since for <T> T anyVararg() the type parameter <T> can be just anything, it can be ResultSetHandler as well. So query(String,Object,ResultSetHandler) also is a match candidate now.
由于我们现在有两种可能的匹配，因此这里适用方法选择的正常程序。是的，这是模棱两可的。第一个参数是相同的， String ，但对于另外两个 ResultSetHandler 比对象但是当一个候选人接受第二个参数的更具体的类型时，另一个候选人接受第三个参数（和后续）。
Since we have two possible matches now, the normal procedure of method selection applies here. And yes, it’s ambiguous. The first parameter is the same, String, but for the other two ResultSetHandler is more specific than Object but while one candidate accepts a more specific type for the second parameter, the other does for the third (and follow-ups).
很明显，允许方法返回类型的类型参数只是一个模糊性的来源，但像Mockito包含这些方法的API是Java编程的一个极端情况。您必须以通用方式强制输入类型 Matchers。< Desired> anyVararg（）或通过类型转换（所需）anyVararg（）。
It’s clear that type parameters that allow a method’s return type to be just anything are a source of ambiguity but APIs like Mockito’s containing such methods are a corner case of Java programming. You will have to force a type either the generic way Matchers.<Desired>anyVararg() or via type cast (Desired)anyVararg().
这篇关于mockito：如何匹配java 8中的varargs？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！