Question

我想理解为什么以下内容无法使用＆＃34;引用不明确＆＃34;当它似乎不应该是。是否值得向javac团队报告？

import java.util.function.Function;
import java.util.function.ToLongFunction;
import org.junit.Test;

public class LambdaTest {

    @FunctionalInterface
    public static interface CheckedFunction<U,R>
    {
        R apply(U value) throws Exception;
    }

    @FunctionalInterface
    public static interface CheckedToLongFunction<T>
    {
        long apply(T i) throws Exception;
    }

    public static <T,R> Function<T,R> unchecked(CheckedFunction<T,R> func)
    {
        return value -> {
            try
            {
                return func.apply (value);
            }
            catch(RuntimeException e)
            {
                throw e;
            }
            catch(Exception e)
            {
                throw new RuntimeException(e);
            }
        };
    }

    public static <T> ToLongFunction<T> unchecked(CheckedToLongFunction<T> func)
    {
        return value -> {
            try
            {
                return func.apply (value);
            }
            catch(RuntimeException e)
            {
                throw e;
            }
            catch(Exception e)
            {
                throw new RuntimeException(e);
            }
        };
    }

      public void 
    bar( Function<Object,Object> fn ) { 

            System.out.println("Function"); 
        }

      @Test public void
    test() {

            bar (a -> a); //OK
            bar (unchecked (a -> a)); //Should be OK, but receive "reference to unchecked is ambiguous"
            bar (unchecked ((Object a) -> a)); //OK
        }

}

正如您所看到的，该示例很有趣，因为CheckedFunction和CheckedToLongFunction都采用引用类型，因此显式指定lamba的输入类型似乎没有任何用处。然而，它让代码编译。

unckeched(CheckedFunction)应该没有歧义地被调用，因为unchecked(CheckedToLongFunction)产生一个返回原语的lambda，而bar需要Object。

我特别期待JLS的决议。如果JLS没有指定，我可以尝试将其归档为javac bug。

Answer 1

你有两种方法

public static <T,R> Function<T,R> unchecked(CheckedFunction<T,R> func)
public static <T> ToLongFunction<T> unchecked(CheckedToLongFunction<T> func)

每个都有一个功能接口类型的参数。

@FunctionalInterface
public static interface CheckedFunction<U, R> {
    R apply(U value) throws Exception;
}

@FunctionalInterface
public static interface CheckedToLongFunction<T> {
    long apply(T i) throws Exception;
}

在适当的背景下，implicitly typed lambda expression a -> a可以应用于其中任何一个。但是，在执行重载解析时似乎没有检查该上下文。

所以虽然

中有a -> a

bar(unchecked(a -> a)); // Should be OK, but receive

无法转换为CheckedToLongFunction实例（因为无法从该调用上下文推断出Long的类型参数），lambda仍然适用于函数类型。

编译器无法确定是否应将a -> a转换为CheckedToLongFunction或CheckedFunction。由于两者都适用，所以调用是不明确的。不检查调用上下文（和返回类型）以解决歧义。

然而，在这种情况下，

bar(unchecked((Object a) -> a)); // OK

我们有一个显式类型 lambda表达式。 lambda主体解析为Object类型的返回值，它不符合CheckedToLongFunction#apply(..)方法的要求，即。类型Object的表达式不能隐式转换为long类型的表达式。

因此，由于还有另一种适用的方法，因此选择了一种方法。

Answer 2

函数声明unchecked(CheckedToLongFunction<T> func)旨在返回ToLongFunction，ToLongFunction返回long。在你的参数中，你声称应该忽略这个函数，因为它返回一个原语（并且可能抛出一个运行时异常）。

通过引入自动装箱，ToLongFunction的原始结果可以装箱到Long，使其成为一个对象。

因此，在与已经相同的上下文中，ToLongFunction可以返回Long和long

因此模棱两可的功能。

请参阅JLS 15.12.2

1 - 第一阶段（第15.12.2.2节）执行重载解析而不允许装箱或拆箱转换，或使用变量arity方法调用。如果在此阶段没有找到适用的方法，则处理继续到第二阶段。

然后

2-第二阶段（§15.12.2.3）执行重载解析，同时允许装箱和拆箱，但仍然排除使用变量arity方法调用。如果在此阶段没有找到适用的方法，则处理继续到第三阶段。

为什么这个与lambda相关的类型推断失败了？

2 个答案: