Question

Guava最近改为require java 8。为什么像Maps这样的类不将java.util.function.Function作为参数而不是com.google.common.base.Function？ com.google.common.base.Function扩展了java.util.function.Function，所以不应该有任何兼容性问题？什么是移植计划？是否有这种方法的22.0版本？

Answer 1

这是否意味着每个已经使用guava的人都必须重新编译他们的代码，因为现在某些方法已经改变了？他们不能简单地升级而不破坏某些代码。

反过来说。这是设置：

class GuavaFun extends JavaFunc {}

class JavaFunc {}

你有这个宣言：

public static void test(GuavaFun f) {

}

这样称呼：

test(new JavaFunc());

会失败。

如果你可以扩展JavaFun并制作它：

class JavaFunc extends GuavaFun {}

然后你可以将一个或另一个传递给测试方法。

如果你的函数声明为java-8之前的样式，那么会破坏，但lambda不会。

 public static void main(String[] args) {

    java.util.function.Function<String, String> f2 = (String b) -> b.toUpperCase();

    test((String a) -> a.toUpperCase());
    test(f2);

}

public static void test(com.google.common.base.Function<String, String> f) {

}

第二次测试调用将失败，而lambda表达式将不会;因为它仍然是@FunctionalInterface。

Answer 2

来自Guava's discussion group：

我们知道我们想要对这些方法进行更改，但是它很复杂，我们尚未制定出完整的计划。关于Guava功能接口的一些实用程序被Java 8完全冗余（参见例如Predicates.instanceOf（Class）与Class :: isInstance），有些像Suppliers.memoize似乎仍然有用 - 我们希望确保我们有一个全面的计划在我们开始改变一切之前如何处理这些方法，我们还没有。

你肯定会在未来的Guava版本中开始看到这些问题的工作，但是现在我认为我们将离开那些方法 - 尽管我们建议将lambda传递给这些方法，在这种情况下，编译器将做正确的事。

- Louis Wasserman

以下列方式回答问题：

为什么guava版本21.0中的地图不将java.util.function.Function等作为参数？

影响太大，当21.0上架时，计划并未完全解决。
Maps这样的课程如何不将java.util.function.Function作为参数而不是com.google.common.base.Function？

与1相同。
com.google.common.base.Function扩展java.util.function.Function，因此不会出现任何兼容性问题？

（仅部分通过引用回答）是的，有一些问题。但为了安全起见，请使用新的lambda表示法。
移植计划是什么？

目前正在制定计划。
这种方法是否有22.0版本？

（报价未涵盖）很可能不是。虽然我不能肯定地说。检查Guava当前分支的源代码，你会发现它仍在使用Guava的Function。

为什么guava版本21.0中的地图不将java.util.function.Function等作为参数？

2 个答案: