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

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

这在我在Java 1.7.0.79(以及1.6.0.31)上运行的Eclipse上运行得很好.

但是,在使用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>>知道signatures是和空方法.

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

我用的是hamcrest 1.3 BTW.

解决方法:

在失败的系统上构建时似乎使用了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在类路径上.