【问题标题】:Why does Function.identity() break type reification but t -> t does not?为什么 Function.identity() 打破类型具体化但 t -> t 没有?
【发布时间】:2016-10-28 08:20:16
【问题描述】:

Java 8 lambdas, Function.identity() or t->t 找到的答案似乎暗示Function.identity() 几乎总是等同于t -> t。但是,在下面看到的测试用例中,将 t -> t 替换为 Function.identity() 会导致编译器错误。这是为什么呢?

public class Testcase {

    public static <T, A, R, K, V> Collector<T, A, R> comparatorOrdering(
            Function<? super T, ? extends K> keyMapper,
            Function<? super T, ? extends V> valueMapper,
            Comparator<? super K> keyComparator,
            Comparator<? super V> valueComparator) {
        return null;
    }

    public static void main(String[] args) {    
        Map<Integer, String> case1 = Stream.of(1, 2, 3).
                collect(comparatorOrdering(t -> t, t -> String.valueOf(t),
                        Comparator.naturalOrder(), Comparator.naturalOrder()));
        Map<Integer, String> case2 = Stream.of(1, 2, 3).
                collect(comparatorOrdering(Function.identity(), t -> String.valueOf(t),
                        Comparator.naturalOrder(), Comparator.naturalOrder()));
    }
}

案例 1 编译得很好,但案例 2 失败:

method comparatorOrdering in class Testcase cannot be applied to given types;
                collect(comparatorOrdering(Function.identity(), t -> String.valueOf(t),
  required: Function<? super T#1,? extends K>,Function<? super T#1,? extends V>,Comparator<? super K>,Comparator<? super V>
  found: Function<Object,Object>,(t)->Strin[...]Of(t),Comparator<T#2>,Comparator<T#3>
  reason: inferred type does not conform to upper bound(s)
    inferred: Object
    upper bound(s): Comparable<? super T#4>,T#4,Object
  where T#1,A,R,K,V,T#2,T#3,T#4 are type-variables:
    T#1 extends Object declared in method <T#1,A,R,K,V>comparatorOrdering(Function<? super T#1,? extends K>,Function<? super T#1,? extends V>,Comparator<? super K>,Comparator<? super V>)
    A extends Object declared in method <T#1,A,R,K,V>comparatorOrdering(Function<? super T#1,? extends K>,Function<? super T#1,? extends V>,Comparator<? super K>,Comparator<? super V>)
    R extends Object declared in method <T#1,A,R,K,V>comparatorOrdering(Function<? super T#1,? extends K>,Function<? super T#1,? extends V>,Comparator<? super K>,Comparator<? super V>)
    K extends Object declared in method <T#1,A,R,K,V>comparatorOrdering(Function<? super T#1,? extends K>,Function<? super T#1,? extends V>,Comparator<? super K>,Comparator<? super V>)
    V extends Object declared in method <T#1,A,R,K,V>comparatorOrdering(Function<? super T#1,? extends K>,Function<? super T#1,? extends V>,Comparator<? super K>,Comparator<? super V>)
    T#2 extends Comparable<? super T#2>
    T#3 extends Comparable<? super T#3>
    T#4 extends Comparable<? super T#4> declared in method <T#4>naturalOrder()

我的环境是 Windows 10,64 位,Oracle JDK build 1.8.0_92-b14。

更新:看到这是在 ecj 下编译的,我有一个后续问题:这是 javac 中的错误吗? JLS对此案有什么看法?

【问题讨论】:

  • 你能分享一些关于你的环境的细节吗?这对我来说编译得很好。
  • 我可以用 Java 1.8.0_92 重现这个。 (OpenJDK)
  • @StephenC 哪个版本的 1.8.0_92?我用的是 1.8.0_92-b14 不能复现。
  • $ java -version ==> openjdk version "1.8.0_92" OpenJDK Runtime Environment (build 1.8.0_92-b14) OpenJDK 64-Bit Server VM (build 25.92-b14, mixed mode) .... 在 Fedora Linux 上
  • 这个错误在javac中不是在ecj中是可以重现的,所以eclipse中没有错误说明不了太多。

标签: java generics reification


【解决方案1】:

Ecj 能够推断出正确的 (?) 类型参数 (Integer) 以匹配约束。 Javac 出于某种原因得出了不同的结果。

这不是 javac/ecj 第一次在推断类型参数时表现不同。

在这种情况下,你可以用 Function.identity() 给 javac 一个提示,让它可以用 javac 编译。

关于Function.identity()和t->t的区别:

  • Function.identity() 是 Function
  • t->t 在这种情况下是 Function

所以 t->t 在可以匹配的方法上更加灵活。

【讨论】:

  • 在指定类型 Integer 后使用 javac 1.8.0_60 编译得很好
  • 我添加了一个后续问题。
【解决方案2】:

i -&gt; iFunction.identity() 之间的区别在以下情况下很明显:(1) 收集器是嵌套的,(2) upcast 需要在深层嵌套的某个地方。

示例:假设我们要将List&lt;Object&gt; 中的元素按元素类分类到具有特定列表的映射中。 (它类似于Guava ClassToInstanceMap,除了值是List,所以类似于假设的ClassToInstanceMultimap。)下游收集器toList() 通常将值收集到List&lt;Object&gt;。但是,如果map的值类型是通配符类型List&lt;?&gt;,类型推断就不能简单匹配。解决方法是让收集器伪装成收集List&lt;?&gt;,由中间的collectingAndThen收集器完成。

现在的重点是,finisher 函数应该是什么样的? Lambda i -&gt; i 的行为类似于 Function&lt;List&lt;Object&gt;, List&lt;?&gt;&gt;,它允许向上转换。 Function.identity() 具有固定输入和输出类型 T 没有我们需要的向上转换空间,因此代码无法编译。

import static java.util.function.Function.identity;
import static java.util.stream.Collectors.collectingAndThen;
import static java.util.stream.Collectors.groupingBy;
import static java.util.stream.Collectors.toList;

public static void main(String[] args) {
    class Apple {}
    class Pear {}
    List<Object> list = List.of(new Apple(), new Pear(), new Apple());
    Map<Class<?>, List<Object>> obj;  
    obj = list.stream().collect(groupingBy(Object::getClass, toList())); // compiles
    Map<Class<?>, List<?>> wild;
    wild = list.stream().collect(groupingBy(Object::getClass, toList())); // wont compile
    wild = list.stream().collect(groupingBy(Object::getClass, collectingAndThen(toList(), i -> i)));  // compiles
    wild = list.stream().collect(groupingBy(Object::getClass, collectingAndThen(toList(), identity())));  // wont compile
    wild = list.stream().collect(groupingBy(Object::getClass, collectingAndThen(toList(), (List<Object> i) -> (List<?>)i)));  // compiles
    System.out.println(wild);
}

【讨论】:

  • 我知道您想提供帮助,但您的回答实际上并没有回答问题。我知道i -&gt; i 的行为与Function.identity() 不同,但是是什么让您相信它应该这样做? JLS 是否指定 i -&gt; i 应该允许向上转换?参考会很有帮助。
猜你喜欢
  • 2015-03-17
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2011-06-14
  • 2013-12-06
  • 2012-08-04
  • 1970-01-01
相关资源
最近更新 更多