Java可以从类型参数边界推断出类型参数吗？

Question

以下测试程序源自一个更复杂的程序,它可以执行一些有用的操作.它与Eclipse编译器成功编译.

import java.util.ArrayList;
import java.util.List;

public class InferenceTest
{
    public static void main(String[] args)
    {
        final List<Class<? extends Foo<?, ?>>> classes =
            new ArrayList<Class<? extends Foo<?, ?>>>();
        classes.add(Bar.class);
        System.out.println(makeOne(classes));
    }

    private static Foo<?, ?> makeOne(Iterable<Class<? extends Foo<?, ?>>> classes)
    {
        for (final Class<? extends Foo<?, ?>> cls : classes)
        {
            final Foo<?, ?> foo = make(cls); // javac error here
            if (foo != null)
                return foo;
        }
        return null;
    }

    // helper used to capture wildcards as type variables
    private static <A, B, C extends Foo<A, B>> Foo<A, B> make(Class<C> cls)
    {
        // assume that a real program actually references A and B
        try
        {
            return cls.getConstructor().newInstance();
        }
        catch (final Exception e)
        {
            return null;
        }
    }

    public static interface Foo<A, B> {}

    public static class Bar implements Foo<Integer, Long> {}
}

但是,使用Oracle JDK 1.7 javac,它失败了:

InferenceTest.java:18: error: invalid inferred types for A,B; inferred type does not
 conform to declared bound(s)
            final Foo<?, ?> foo = make(cls);
                                      ^
    inferred: CAP#1
    bound(s): Foo<CAP#2,CAP#3>
  where A,B,C are type-variables:
    A extends Object declared in method <A,B,C>make(Class<C>)
    B extends Object declared in method <A,B,C>make(Class<C>)
    C extends Foo<A,B> declared in method <A,B,C>make(Class<C>)
  where CAP#1,CAP#2,CAP#3 are fresh type-variables:
    CAP#1 extends Foo<?,?> from capture of ? extends Foo<?,?>
    CAP#2 extends Object from capture of ?
    CAP#3 extends Object from capture of ?
1 error

哪个编译器是对的？

上面输出的一个可疑方面是CAP#1 extends Foo<?,?>.我希望类型变量的范围是CAP#1 extends Foo<CAP#2,CAP#3>.如果是这种情况,那么推断的边界CAP#1将符合声明的边界.但是,这可能是一个红色的鲱鱼,因为确实应该推断出C CAP#1,但错误信息是关于A和B.

---

请注意,如果我用以下代码替换第26行,则两个编译器都接受该程序:

private static <C extends Foo<?, ?>> Foo<?, ?> make(Class<C> cls)

但是,现在我无法引用捕获的Foo参数类型.

更新:两个编译器同样接受(但也无用)是这样的:

private static <A, B, C extends Foo<? extends A, ? extends B>>
    Foo<? extends A, ? extends B> make(Class<C> cls)

它本质上导致A并且B被简单地推断为Object,因此在任何情况下显然都没有用.但是,它确实证实了我的理论,javac它只会对通配符边界进行推断,而不是捕获边界.如果没有人有更好的想法,这可能是(不幸的)答案.(最终更新)

---

我意识到整个问题可能是TL; DR,但我会​​继续以防其他人遇到这个问题......

基于JLS 7,§15.12.2.7基于实际参数推断类型参数,我做了以下分析:

鉴于形式的约束A << F,A = F或A >> F:

最初,我们有以下形式的一个约束A << F,这表明该类型A可转换为输入F由方法调用转换(§5.3).在这里,A是Class<CAP#1 extends Foo<CAP#2, CAP#3>>和F是Class<C extends Foo<A, B>>.请注意,其他约束形式(A = F和A >> F)仅在推理算法递归时出现.

接下来,C应该CAP#1通过以下规则推断:

(2.)否则,如果约束具有以下形式A << F:

• 如果F具有如下形式G<..., Yk-1, U, Yk+1, ...>,其中U是,涉及型表达Tj,则如果A具有如下形式的超类型G<..., Xk-1, V, Xk+1, ...> ,其中V是一种类型的表达,这种算法递归地应用到该约束V = U.

这里,G是Class,U并且Tj是C和V是CAP#1.递归应用程序CAP#1 = C应该导致约束C = CAP#1:

(3.)否则,如果约束具有以下形式A = F:

• 如果F = Tj,则表示约束Tj = A.

到目前为止,分析似乎与javac输出一致.也许分歧的关键是是否继续尝试推断A和B.例如,给定此规则

• 如果F有形式G<..., Yk-1, ? extends U, Yk+1, ...>,U涉及的地方Tj,那么如果A有一个超类型是:
  • G<..., Xk-1, V, Xk+1, ...>,哪里V是类型表达式.
  • G<..., Xk-1, ? extends V, Xk+1, ...>.

然后该算法递归地应用于约束V << U.

如果CAP#1被认为是通配符(它是捕获的),则应用此规则,并使用Uas Foo<A, B>和Vas 递归地继续推断Foo<CAP#2, CAP#3>.如上所述,这将产生A = CAP#2和B = CAP#3.

但是,如果CAP#1只是一个类型变量,那么这些规则似乎都没有考虑它的界限.也许在规范部分末尾的这种让步引用了这样的情况:

类型推断算法应被视为启发式算法,旨在在实践中表现良好.如果它无法推断出期望的结果,则可以使用显式类型参数.

显然,通配符不能用作显式类型参数.:-(

Answer 1

问题是您从以下推理约束开始:

class<#1>, #1 <: Foo<?, ?>

这为您提供了C的解决方案,即C =#1.

然后你需要检查C是否符合声明的边界 - C的边界是Foo,所以你最终得到这个检查:

#1 <: Foo<A,B>

可以改写为

Bound(#1) <: Foo<A, B>

因此:

Foo<?, ?> <: Foo<A, B>

现在,编译器在这里进行LHS的捕获转换(这里是生成#2和#3的地方):

Foo<#2, #3> <: Foo<A, B>

意思是

A = #2

B = #3

所以,我们的解决方案是{A =#2,B =#3,C =#1}.

这是一个有效的解决方案？为了回答这个问题,我们需要在类型替换后检查推断类型是否与推理变量边界兼容,因此:

[A:=#2]A <: Object
#2 <: Object - ok

[B:=#3]B <: Object
#3 <: Object - ok

[C:=#1]C <: [A:=#2, B:=#3]Foo<A, B>
#1 <: Foo<#2, #3>
Foo<?, ?> <: Foo<#2, #3>
Foo<#4, #5> <: Foo<#2, #3> - not ok

因此错误.

当涉及推理和捕获类型之间的相互作用时,规范是不明确的,因此在不同编译器之间切换时有不同的行为是很正常的(但不是很好!).然而,从编译器角度和JLS角度来看,其中一些问题正在得到解决,所以这样的问题应该在中期得到解决.