流中收集器中的比较器导致类型推断问题？

Question

我有以下简化的示例，以TreeMap从Integer到List的形式将html" target="_blank">字符串列表分组为类别

public static void main(String[] args)
{
    List<String> list = Arrays.asList("A", "B", "C", "D", "E");

    TreeMap<Integer, List<String>> res = list.stream()
        .collect(Collectors.groupingBy(
            s -> s.charAt(0) % 3,
            () -> new TreeMap<>(Comparator.<Integer>reverseOrder()), // Type required
            Collectors.toList()
        ));

    System.out.println(res);
}

如果我未指定Comparator.reverseOrder（）的类型，则代码将无法编译（有关错误，请参见文章底部）。

如果我明确指定TreeMap的类型而不是Comparator.reverseOrder（）的类型，则代码可以正常工作。

() -> new TreeMap<Integer, List<String>>(Comparator.reverseOrder()), // Type required

所以：

• 编译器能够推断出TreeMap的类型
• 如果编译器知道TreeMap的类型，则它能够推断Comparator的类型。
• 但是，如果编译器必须推断出TreeMap的类型，则它无法弄清Comparator的类型。

我不明白为什么编译器无法推断两种类型。我已经使用Oracle的JDK 1.8.0_191和AdoptOpenJDK的JDK
11.0.1_13进行了测试，结果相同。

这是我不知道的一些限制吗？

Error:(22, 32) java: no suitable method found for groupingBy((s)->s.cha[...]) % 3,()->new Tr[...]er()),java.util.stream.Collector<java.lang.Object,capture#1 of ?,java.util.List<java.lang.Object>>)
    method java.util.stream.Collectors.<T,K>groupingBy(java.util.function.Function<? super T,? extends K>) is not applicable
      (cannot infer type-variable(s) T,K
        (actual and formal argument lists differ in length))
    method java.util.stream.Collectors.<T,K,A,D>groupingBy(java.util.function.Function<? super T,? extends K>,java.util.stream.Collector<? super T,A,D>) is not applicable
      (cannot infer type-variable(s) T,K,A,D
        (actual and formal argument lists differ in length))
    method java.util.stream.Collectors.<T,K,D,A,M>groupingBy(java.util.function.Function<? super T,? extends K>,java.util.function.Supplier<M>,java.util.stream.Collector<? super T,A,D>) is not applicable
      (inferred type does not conform to upper bound(s)
        inferred: java.lang.Object
        upper bound(s): java.lang.Comparable<? super T>,T,java.lang.Object)

Answer 1

不幸的是，类型推断具有非常复杂的规范，这使得很难确定特定的奇怪行为是符合规范还是仅是编译器错误。

类型推断有两个众所周知的故意限制。

首先，表达式的目标类型不用于接收方表达式，即在方法调用链中。所以当你有一个形式的声明

TargetType x = first.second(…).third(…);

在TargetType将使用推断通用类型的third()调用和它的参数表现，而不是second(…)调用。因此，类型推断second(…)只能使用和的独立类型first。

这不是问题。由于独立型list的好定义为List<String>，存在推断的结果类型没问题Stream<String>的stream()电话，有问题的collect调用链，可以使用目标类型的最后一个方法调用TreeMap<Integer, List<String>>推断类型参数。

第二个限制是关于过载解析。语言设计人员在涉及不完整类型的参数表达式之间的循环依赖时需要进行切入，后者需要先了解实际的目标方法及其类型，然后才能帮助确定正确的调用方法。

这在这里也不适用。当groupingBy重载时，这些方法的参数数量有所不同，这允许在不知道参数类型的情况下选择唯一合适的方法。还可以证明，当我们替换groupingBy为具有预期签名但没有重载的其他方法时，编译器的行为不会改变。

您的问题可以通过使用解决，例如

TreeMap<Integer, List<String>> res = list.stream()
    .collect(Collectors.groupingBy(
        (String s) -> s.charAt(0) % 3,
        () -> new TreeMap<>(Comparator.reverseOrder()),
        Collectors.toList()
    ));

这为分组函数使用了显式类型化的lambda表达式，尽管该表达式实际上并未对映射键的类型有所贡献，但会导致编译器找到实际的类型。

如上所述，虽然使用显式类型的lambda表达式而不是隐式类型的表达式可以在方法重载解析上有所不同，但在此不应该将其应用，因为这种特定情况不是重载方法的问题。

足够奇怪的是，甚至以下更改也使编译器错误消失了：

static <X> X dummy(X x) { return x; }
…

TreeMap<Integer, List<String>> res = list.stream()
    .collect(Collectors.groupingBy(
        s -> s.charAt(0) % 3,
        dummy(() -> new TreeMap<>(Comparator.reverseOrder())),
        Collectors.toList()
    ));

在这里，我们没有帮助任何其他显式类型，也没有改变lambda表达式的形式性质，但是，编译器仍然突然正确地推断出所有类型。

该行为似乎与以下事实有关：零参数lambda表达式始终被显式键入。由于我们无法更改零参数lambda表达式的性质，因此我创建了以下替代收集器方法进行验证：

public static <T, K, D, A, M extends Map<K, D>>
Collector<T, ?, M> groupingBy(Function<? super T, ? extends K> classifier,
                              Function<Void,M> mapFactory,                                 
                              Collector<? super T, A, D> downstream) {
    return Collectors.groupingBy(classifier, () -> mapFactory.apply(null), downstream);
}

然后，使用隐式类型的lambda表达式作为map factory进行编译时不会出现问题：

TreeMap<Integer, List<String>> res = list.stream()
    .collect(groupingBy(
        s -> s.charAt(0) % 3,
        x -> new TreeMap<>(Comparator.reverseOrder()),
        Collectors.toList()
    ));

而使用显式类型的lambda表达式会导致编译器错误：

TreeMap<Integer, List<String>> res = list.stream()
    .collect(groupingBy(                           // compiler error
        s -> s.charAt(0) % 3,
        (Void x) -> new TreeMap<>(Comparator.reverseOrder()),
        Collectors.toList()
    ));

在我看来，即使规范支持此行为，也应予以纠正，因为提供显式类型的含义绝不应该是类型推断比没有条件推断更糟。对于零参数lambda表达式尤其如此，我们不能将其转换为隐式类型的表达式。

它还没有解释为什么将所有参数都转换为显式类型的lambda表达式也可以消除编译器错误。