Question

这是我在其中一个项目中完成的简化版本：

List<String> names = ...
assertThat(names, is(empty()));

这对我在Eclipse 1.7.0.79上运行的Eclipse（以及1.6.0.31）运行良好。

但是，在使用Java 1.7.0.55（和1.6.0.29）的远程系统上编译失败，并且出现以下错误消息：

no suitable method found for assertThat(java.util.List<String>,org.hamcrest.Matcher<java.util.Collection<java.lang.Object>>)
    method org.hamcrest.MatcherAssert.<T>assertThat(T,org.hamcrest.Matcher<? super T>) is not applicable
      (actual argument org.hamcrest.Matcher<java.util.Collection<java.lang.Object>> cannot be converted to org.hamcrest.Matcher<? super java.util.List<String>> by method invocation conversion)
    method org.hamcrest.MatcherAssert.<T>assertThat(java.lang.String,T,org.hamcrest.Matcher<? super T>) is not applicable
      (cannot instantiate from arguments because actual and formal argument lists differ in length)
    method org.hamcrest.MatcherAssert.assertThat(java.lang.String,boolean) is not applicable
      (actual argument java.util.List<String> cannot be converted to java.lang.String by method invocation conversion)

我希望第一个重载版本符合我的情况，但由于看似不确定的类型推断而没有。为什么编译器似乎认为实际参数属于org.hamcrest.Matcher<java.util.Collection<java.lang.Object>>类型，显然应该org.hamcrest.Matcher<java.util.Collection<? extends java.lang.Object>>知道is empty和{{1}}方法。

问题是我对远程系统上可以切换到的JDK的控制有限，这是一个刺激。测试代码，我也不允许解决这个问题。 所以，目前我正在尝试做的只是了解问题是否是由于对所述JDK的错误类型推断造成的。不可否认，我还没有尝试过同样的方法。在我个人电脑上的JDK上。

我使用hamcrest 1.3 BTW。

Answer 1

在构建失败的系统上使用Hamcrest 1.2似乎。当我使用Hamcrest 1.2构建代码时，它在使用1.3时失败并显示相同的错误消息。检查Hamcrest代码后，Matchers.empty()签名在1.3中发生了变化：

public static <E> org.hamcrest.Matcher<java.util.Collection<E>> empty() // 1.2

到

public static <E> org.hamcrest.Matcher<java.util.Collection<? extends E>> empty() // 1.3

这可以解释为什么它在1.2上失败但在1.3上工作。

您应该检查项目设置和系统设置，以确保在构建时只有hamcrest 1.3在类路径上。

Hamcrest断言 - 类型推断

1 个答案: