Java 8 Friday：语言设计很微妙

最新推荐文章于 2021-11-30 17:13:19 发布

dnc8371

最新推荐文章于 2021-11-30 17:13:19 发布

阅读量116

点赞数

文章标签： java 人工智能大数据 python 编程语言

在Data Geekery ，我们喜欢Java。而且，由于我们真的很喜欢jOOQ的流畅的API和查询DSL ，我们对Java 8将为我们的生态系统带来什么感到非常兴奋。

Java 8星期五

每个星期五，我们都会向您展示一些不错的教程风格的Java 8新功能，这些功能利用了lambda表达式，扩展方法和其他好东西。您可以在GitHub上找到源代码。

语言设计微妙

对我们来说这是忙碌的一周。出于以下两个原因，我们刚刚将jOOQ集成测试迁移到了Java 8：

我们要确保客户端代码可以使用Java 8进行编译
我们开始无聊重复编写相同的旧循环

触发器是一个循环，在该循环中，我们需要将SQLDialect[]转换为另一个对每个数组元素调用.family() SQLDialect[] 。考虑：

Java 7

SQLDialect[] families = 
    new SQLDialect[dialects.length];
for (int i = 0; i < families.length; i++)
    families[i] = dialects[i].family();

Java 8

SQLDialect[] families = 
Stream.of(dialects)
      .map(d -> d.family())
      .toArray(SQLDialect[]::new);

好的，事实证明这两种解决方案都同样冗长，即使后者感觉更优雅。

这使我们直接进入下一个主题：

向后兼容

出于向后兼容的原因，尚未对数组和现有的Collections API进行改装，以适应Streams现在拥有的所有有用方法。换句话说，数组没有map()方法，就像List没有这种方法一样。流和集合/数组是正交的世界。我们可以将它们彼此转换，但是它们没有统一的API。

这在日常工作中很好。毫无疑问，我们会习惯Streams API，并且会喜欢它。但是由于Java非常重视向后兼容性，因此我们将不得不更深入地考虑一两个问题。

最近，我们发表了一篇有关Java 8的黑暗面的文章。尽管我们认为这是一个温和的话，但这还是有点a之以鼻（现在是时候提出一些批评了，毕竟我们之前在我们的系列文章中一直给Java 8赞美）。首先，该帖子引发了Informatech的朋友Edwin Dalorzo的反应。（之前，Edwin写了这篇很棒的文章，比较了LINQ和Java 8 Streams ）。我们本文的批评主要围绕三个方面进行：

重载变得更加复杂（另请参见此编译器错误）
对默认方法的方法修饰符的支持有限
流和功能接口的原始类型“ API重载”

Brian Goetz的回应

然后，我收到了来自布莱恩·戈茨（ Brian Goetz）自己的一封私人邮件，他向我指出了一些我尚未想到的事情：

我仍然认为您专注于错误的事情。它并不是您不喜欢的语法；它是模型-您不需要“默认方法”，您需要特征，而语法只是在提醒您您没有获得所需的功能。（但是，如果我们删除了“ default”关键字，您会更加困惑“为什么它们不能成为最终的！”）但这是在指使者（这里的关键词是使者）。

公平地说“这不是我想要的模型”。森林中有许多可能的道路，很可能未走的道路同样好或更好。

这也是埃德温的结论。默认方法是解决使Java 8有用的所有新API的必要手段。如果必须调整Iterator ， Iterable ， List ， Collection和所有其他现有接口以适应lambda和Streams API交互，则专家组将需要打破大量API。相反，如果不添加这些附加的实用程序方法（例如，参见令人敬畏的新Map方法！），Java 8的性能将仅为其一半。

就是这样。

即使也许更多的类构建工具可能有用，但对于已经做好很多事情来解决问题的专家组来说，它们也不是重点。重点是为API演变提供一种方法。或用Brian Goetz自己的话说：

@breandan @lukaseder希望它能使一些人意识到“哎呀，这种语言设计的东西比我想象的要微妙得多”。

— Brian Goetz（@BrianGoetz） 2014年5月6日

接触社区

很好，Brian Goetz向社区伸出了援助之手，以帮助我们获得有关Java 8的正确图片。他没有在私人消息中解释有关专家组决策的理由，而是让我在Stack Overflow上再次公开提问（或lambda-dev），这样他就可以公开回答他们了。为了增加宣传和更大的社区利益，我选择了Stack Overflow。这里是：

立刻获得这两个问题的牵引力表明这些东西对社区有多么重要，因此请不要错过阅读它们的机会！

但是很稳定！

Java可能没有node.js具有的“酷”的光环。您可能会想使用JavaScript语言（只要它包含脏话），但是从平台营销的角度来看，Java长期以来一直是第一次受到挑战–并且“不酷”并倒退-兼容无助于保持开发人员的兴趣。

但是，让我们从长远考虑，而不是顺应潮流。拥有如此出色的专业平台，例如Java语言，JVM，JDK，JEE等，是无价的。因为归根结底，“不可思议”的向后兼容性也可能很棒。如前所述，我们已经将集成测试升级到Java8。不是一个编译错误，也不是一个错误。使用Eclipse对Java 8的BETA支持，我可以轻松地将匿名类转换为lambda，并编写令人敬畏的东西，例如这些即将到来的jOOQ 3.4嵌套事务（API尚未最终实现）：

ctx.transaction(c1 -> {
    DSL.using(c1)
       .insertInto(AUTHOR, AUTHOR.ID, AUTHOR.LAST_NAME)
       .values(3, "Doe")
       .execute();

    // Implicit savepoint here
    try {
        DSL.using(c1).transaction(c2 -> {
            DSL.using(c2)
               .update(AUTHOR)
               .set(AUTHOR.FIRST_NAME, "John")
               .where(AUTHOR.ID.eq(3))
               .execute();

            // Rollback to savepoint
            throw new MyRuntimeException("No");
        });
    }

    catch (MyRuntimeException ignore) {}

    return 42;
});

因此，归根结底，Java很棒。 Java 8是对以前版本的巨大改进，并且在专家组中有很多人（并通过社交媒体与社区联系），我相信Java 9会更好。特别是，我期待了解这两个项目的发展方式：

尽管再次，我真的很好奇，他们将如何从向后兼容性的角度来实现这两项改进，以及之后需要了解哪些警告。

无论如何，我们希望专家组将继续就Stack Overflow提供公众反馈。