引用与泛型不明确

Question

我在这里遇到了一个关于泛型和方法重载的非常棘手的情况。查看这个示例类：

public class Test {
    public <T> void setValue(Parameter<T> parameter, T value) {
    }

    public <T> void setValue(Parameter<T> parameter, Field<T> value) {
    }

    public void test() {
        // This works perfectly. <T> is bound to String
        // ambiguity between setValue(.., String) and setValue(.., Field)
        // is impossible as String and Field are incompatible
        Parameter<String> p1 = getP1();
        Field<String> f1 = getF1();
        setValue(p1, f1);

        // This causes issues. <T> is bound to Object
        // ambiguity between setValue(.., Object) and setValue(.., Field)
        // is possible as Object and Field are compatible
        Parameter<Object> p2 = getP2();
        Field<Object> f2 = getF2();
        setValue(p2, f2);
    }

    private Parameter<String> getP1() {...}
    private Parameter<Object> getP2() {...}

    private Field<String> getF1() {...}
    private Field<Object> getF2() {...}
}

上面的示例在 Eclipse (Java 1.6) 中完美编译，但不能使用 Ant javac 命令（或使用 JDK 的 javac 命令），在第二次调用 时，我会收到此类错误消息设置值：

对 setValue 的引用不明确， 两种方法 setValue(org.jooq.Parameter,T) 在测试和方法中 setValue(org.jooq.Parameter,org.jooq.Field) 在测试赛中

根据规范以及我对Java编译器如何工作的理解，应始终选择最具体的方法： http://java.sun.com/docs/books/jls/third_edition/html/expressions.html#20448

在任何情况下，即使 绑定到 Object，这使得两个 setValue 方法都可以接受调用，即带有 Field 的方法code> 参数似乎总是更具体。它可以在 Eclipse 中运行，只是不能与 JDK 的编译器一起运行。

更新：

像这样，它可以在 Eclipse 和 JDK 编译器中工作（当然，带有 rawtypes 警告）。据我了解，规范中指定的规则当涉及泛型时， 非常特殊。但我发现这相当令人困惑：

    public <T> void setValue(Parameter<T> parameter, Object value) {
    }

    // Here, it's easy to see that this method is more specific
    public <T> void setValue(Parameter<T> parameter, Field value) {
    }

更新 2：

即使使用泛型，我也可以创建此解决方法，避免类型 绑定到 Object< /code> 在 setValue 调用时，通过添加一个名为 setValue0 的附加、明确的间接寻址。这让我认为 T 到 Object 的绑定确实是造成这里所有麻烦的原因：

    public <T> void setValue(Parameter<T> parameter, T value) {
    }

    public <T> void setValue(Parameter<T> parameter, Field<T> value) {
    }

    public <T> void setValue0(Parameter<T> parameter, Field<T> value) {
        // This call wasn't ambiguous in Java 7
        // It is now ambiguous in Java 8!
        setValue(parameter, value);
    }

    public void test() {
        Parameter<Object> p2 = p2();
        Field<Object> f2 = f2();
        setValue0(p2, f2);
    }

我是否误解了这里的某些内容？是否存在与此相关的已知编译器错误？或者是否有解决方法/编译器设置可以帮助我？

后续：

对于那些感兴趣的人，我已经向 Oracle 和 Eclipse 提交了错误报告。 Oracle已经接受了这个bug，到目前为止，Eclipse已经分析了它并拒绝了它！看来我的直觉是正确的，这是 javac

• https://bugs.java.com/bugdatabase/view_bug?bug_id=7031404
• https://bugs.eclipse.org/bugs/show_bug.cgi?id=340506
• https://bugs.eclipse.org/bugs/show_bug.cgi?id=469014（Eclipse Mars 中的新问题）

Answer 1

JDK是对的。第二种方法并不比第一种更具体。来自 JLS3#15.12.2.5

“非正式的直觉是，如果第一个方法处理的任何调用可以传递给另一个方法而不会出现编译时类型错误，则一个方法比另一个方法更具体。 ”

显然这里的情况并非如此。我强调了任何调用。一种方法比另一种方法更具体的属性完全取决于这两种方法本身；每次调用它都不会改变。

对你的问题进行正式分析：m2 比 m1 更具体吗？

m1: <R> void setValue(Parameter<R> parameter, R value) 
m2: <V> void setValue(Parameter<V> parameter, Field<V> value) 

首先，编译器需要从初始约束推断 R：

Parameter<V>   <<   Parameter<R>
Field<V>       <<   R

根据 15.12.2.7 中的推断规则，结果为 R=V

现在我们替换 R 并检查子类型关系

Parameter<V>   <:   Parameter<V>
Field<V>       <:   V

第二个根据 4.10.2 中的子类型规则，该行不成立。所以m2并不比m1更具体。

在此分析中，V 不是 Object；该分析考虑了V的所有可能值。

我建议使用不同的方法名称。超载从来都不是必要的。

---

这似乎是 Eclipse 中的一个重大错误。规范非常清楚地表明类型变量在此步骤中不会被替换。 Eclipse 显然首先进行类型变量替换，然后检查方法特异性关系。

如果这种行为在某些示例中更为“明智”，那么在其他示例中则不然。说

m1: <T extends Object> void check(List<T> list, T obj) { print("1"); }
m2: <T extends Number> void check(List<T> list, T num) { print("2"); }

void test()
    check( new ArrayList<Integer>(), new Integer(0) );

“直观地”，正式按照规范，m2 比 m1 更具体，并且测试打印“2”。但是，如果先进行替换 T=Integer，则这两种方法将变得相同！

---

对于Update 2

m1: <R> void setValue(Parameter<R> parameter, R value) 
m2: <V> void setValue(Parameter<V> parameter, Field<V> value) 

m3: <T> void setValue2(Parameter<T> parameter, Field<T> value)
s4:             setValue(parameter, value)

这里，m1不适用于方法调用s4，因此m2是唯一的选择。

根据15.12.2.2，为了判断m1是否适用于s4，首先进行类型推断，得出R=T的结论；然后我们检查 Ai :< Si，导致Field <: T，这是错误的。

这与之前的分析一致——如果m1适用于s4，那么m2处理的任何调用（本质上与s4相同）都可以由m1处理，这意味着m2将比m1更具体，这是错误的。

在参数化类型中

考虑以下代码

class PF<T>
{
    public void setValue(Parameter<T> parameter, T value) {
    }

    public void setValue(Parameter<T> parameter, Field<T> value) {
    }
}

void test()

    PF<Object> pf2 = null;

    Parameter<Object> p2 = getP2();
    Field<Object> f2 = getF2();

    pf2.setValue(p2,f2);

编译没有问题。根据 4.5.2，PF

    public void setValue(Parameter<Object> parameter, Object value) 

    public void setValue(Parameter<Object> parameter, Field<Object> value) 

第2个方法比第1个更具体。

Answer 2

我的猜测是编译器正在按照 JLS，第 15.12.2.5 节。

对于本节，编译器使用强子类型< /strong> （因此不允许任何未经检查的转换），因此，T value 变为 Object value 且 Field 变为 Object value 。 value 变为 Field

方法m适用于
子类型当且仅当两者
满足以下条件：

* 对于 1 英寸，可以：
      o Ai 是 Si 的亚型 (§4.10) (Ai <: Si) 或
      o Ai 可通过未经检查的转换转换为某种类型 *Ci*

(§5.1.9)，且 Ci <：Si。
* 如果 m 是如上所述的通用方法，则 Ul <: Bl[R1 = U1,
...，Rp = 向上]，1lp。

（参见第 2 点）。由于 Field

对于String和Field，两者之间没有子类型关系。

附言。这是我对事情的理解，请勿将其引用为犹太洁食。

Answer 3

编辑：这个答案是错误的。看看接受的答案。

我认为问题归结为：编译器没有将 f2 的类型（即 Field）和形式参数的推断类型（即 Field -> Field）视为同一类型。

换句话说，看起来f2（Field）的类型被认为是形参Field（Field）类型的子类型。由于 Field 是同一类型的 Object 子类型，因此编译器无法选择一种方法而不是另一种方法。

编辑：让我稍微扩展一下我的陈述

这两种方法都是适用，它看起来像 阶段 1：通过子类型识别适用的匹配数量方法 用于决定调用哪个方法以及来自 选择最具体的方法已应用，但由于某种原因未能选择第二种方法而不是第一种方法。

阶段 1 部分使用以下表示法：X <: S（X 是 S 的子类型）。根据我对 <: 的理解，X <: X 是一个有效的表达式，即 <: 并不严格，包括在此上下文中类型本身（X 是 X 的子类型）。这解释了第一阶段的结果：两种方法都被选为候选方法，因为 Field

选择最具体的方法部分使用相同的符号来表示一种方法比另一种方法更具体。有趣的部分是以“一个名为 m 的固定数量成员方法比另一个成员更具体......”开头的段落。除其他外，它具有：

对于从 1 到 n 的所有 j，Tj <: Sj。

这让我认为在我们的例子中，必须选择第二个方法而不是第一个方法，因为以下内容成立：

• Parameter
• 字段<对象> <: Object

而反过来则不成立，因为 Object <: Field

注意：对于字符串示例，第一阶段将简单地选择唯一适用的方法：第二个。

所以，回答你的问题：我认为这是编译器实现中的一个错误。 Eclipse 有它自己的增量编译器，看起来没有这个错误。