Java 8泛型方法...不适用于Eclipse中的参数

Question

在我们的代码库从java 1.7迁移到1.8的过程中，我们得到了一个错误消息“方法...不适用于几个代码位置上的参数，它们都遵循泛型用法中的相同模式。

我们目前主要在Windows 7上使用Eclipse Mars（4.5.2），但也可以使用Neon（4.6）确认行为。Javac以及符合级别为1.7的ecj都可以编译我们的代码而不会出错。

下面是一个最小、完整且可验证的示例：

public class ComplexInterfaceTest {

  public static class Foo {}

  public interface Bar {
    void print();
  }

  public static class SubFooBar extends Foo implements Bar {
    public void print() {
      System.out.println(this.getClass().getSimpleName());
    }
  }

  public static class FooBar<T extends Foo & Bar> {
    public static <T extends Foo & Bar> FooBar<T> makeFooBar() {
      return new FooBar<>();
    }

    public void create(T value) {
      value.print();
      return;
    }
  }

  public static class Base<T extends Foo> {}

  public static class Subclass extends Base<SubFooBar> {
    public void doSomething(SubFooBar value) {
//      FooBar.<SubFooBar>makeFooBar().create(value);
      FooBar.makeFooBar().create(value);
    }
  }

  public static void main(String[] args) {
    new Subclass().doSomething(new SubFooBar());
  }

}

现在，在 do 中切换注释掉的行某些方法会使代码编译，因此我们确实有一个解决方法。仍然错误消息似乎不正确，因为类子FooBar扩展了Foo并实现了Bar，因此它履行了

我搜索了类似的问题，发现了这些：类型推断JDK8 javac/Eclipse Luna的差异？使用Java8但不使用Java7的Eclipse中的类型推断编译器错误

这让我觉得这可能是一个< code>ecj错误。在本课程中，我还研究了< code>Eclipse Bugzilla,但找不到任何类似的内容，我看到了以下内容:

• 430686已验证固定-我的不是
• 440019与标量类型有关-我的不是
• 492838,448793与通配符有关-我的不是

现在，Eclipse Bugzilla讨论中充满了关于ecj内部工作的细节，我并不总是能理解这些细节。但我所理解的是，那里的普遍共识是，Eclipse编译器必须严格遵循JLS，而不是javac（在出现错误的情况下），所以它不一定是 中的bug。如果它不是一个 ecjbug，那么编译代码一定是一个 javacbug。

我感兴趣的是——对于那些可以分析我的代码片段的类型推理过程的人来说——代码应该已经编译过了，还是我在编码中犯了错误？

编辑

正如我promise将我的报告结果发布到Eclipse的Bugzilla：该缺陷的ID为#497905（Stephan Herrmann已在接受的答案下方的评论中发布了链接），目前针对v4.7。

Answer 1

在该方法中

public void doSomething(SubFooBar value) {
  FooBar.makeFooBar().create(value);
}

方法< code>makeFooBar()的类型参数< code>T永远不会被推断为< code>SubFooBar。事实上，您将随后将< code>SubFooBar的实例传递给< code>create方法，这不会影响前面的调用表达式< code>FooBar.makeFooBar()的类型。

Java不会改变这一点

因此，在所有版本中，为makeFooBar（）调用的T>推断的类型将是交叉类型

这意味着您可以将SubFooBar实例作为传递给create方法FooBar

可以证明 Eclipse 确实推断出与所有其他编译器相同的类型，就像插入适当的类型强制转换一样

public void doSomething(SubFooBar value) {
  FooBar.makeFooBar().create((Foo&Bar)value);
}

使编译器错误消失。所以这里的问题不是类型推断，而是这个Eclipse版本认为< code>SubFooBar不可分配给< code>Foo