在Data Geekery ，我們喜歡Java。 而且，由于我們真的很喜歡jOOQ的流暢的API和查詢DSL ，我們對(duì)Java 8將為我們的生態(tài)系統(tǒng)帶來(lái)什么感到非常興奮。

Java 8星期五

每個(gè)星期五，我們都會(huì)向您展示一些不錯(cuò)的教程風(fēng)格的Java 8新功能，這些功能利用了lambda表達(dá)式，擴(kuò)展方法和其他好東西。 您可以在GitHub上找到源代碼 。

語(yǔ)言設(shè)計(jì)微妙

對(duì)我們來(lái)說(shuō)這是忙碌的一周。 出于以下兩個(gè)原因，我們剛剛將jOOQ集成測(cè)試遷移到了Java 8：

• 我們要確保客戶端代碼可以使用Java 8進(jìn)行編譯
• 我們開始無(wú)聊重復(fù)編寫相同的舊循環(huán)

觸發(fā)器是一個(gè)循環(huán)，在該循環(huán)中，我們需要將SQLDialect[]轉(zhuǎn)換為另一個(gè)對(duì)每個(gè)數(shù)組元素調(diào)用.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);

好的，事實(shí)證明這兩種解決方案都同樣冗長(zhǎng)，即使后者感覺更優(yōu)雅。

這使我們直接進(jìn)入下一個(gè)主題：

向后兼容

出于向后兼容的原因，尚未對(duì)數(shù)組和現(xiàn)有的Collections API進(jìn)行改裝，以適應(yīng)Streams現(xiàn)在擁有的所有有用方法。 換句話說(shuō)，數(shù)組沒有map()方法，就像List沒有這種方法一樣。 流和集合/數(shù)組是正交的世界。 我們可以將它們彼此轉(zhuǎn)換，但是它們沒有統(tǒng)一的API。

這在日常工作中很好。 毫無(wú)疑問(wèn)，我們會(huì)習(xí)慣Streams API，并且會(huì)喜歡它 。 但是由于Java非常重視向后兼容性，因此我們將不得不更深入地考慮一兩個(gè)問(wèn)題。

最近，我們發(fā)表了一篇有關(guān)Java 8的黑暗面的文章 。 盡管我們認(rèn)為這是一個(gè)溫和的話，但這還是有點(diǎn)a之以鼻（ 現(xiàn)在是時(shí)候提出一些批評(píng)了，畢竟我們之前在我們的系列文章中一直給Java 8贊美 ）。 首先，該帖子引發(fā)了Informatech的朋友Edwin Dalorzo的反應(yīng) 。 （之前，Edwin寫了這篇很棒的文章，比較了LINQ和Java 8 Streams ）。 我們本文的批評(píng)主要圍繞三個(gè)方面進(jìn)行：

• 重載變得更加復(fù)雜（ 另請(qǐng)參見此編譯器錯(cuò)誤 ）
• 對(duì)默認(rèn)方法的方法修飾符的支持有限
• 流和功能接口的原始類型“ API重載”

Brian Goetz的回應(yīng)

然后，我收到了來(lái)自布萊恩·戈茨 （ Brian Goetz）自己的一封私人郵件，他向我指出了一些我尚未想到的事情：

我仍然認(rèn)為您專注于錯(cuò)誤的事情。 它并不是您不喜歡的語(yǔ)法； 它是模型-您不需要“默認(rèn)方法”，您需要特征，而語(yǔ)法只是在提醒您您沒有獲得所需的功能。 （但是，如果我們刪除了“ default”關(guān)鍵字，您會(huì)更加困惑“為什么它們不能成為最終的！”）但這是在指使者（這里的關(guān)鍵詞是使者）。

公平地說(shuō)“這不是我想要的模型”。 森林中有許多可能的道路，很可能未走的道路同樣好或更好。

這也是埃德溫的結(jié)論。 默認(rèn)方法是解決使Java 8有用的所有新API的必要手段。 如果必須調(diào)整Iterator ， Iterable ， List ， Collection和所有其他現(xiàn)有接口以適應(yīng)lambda和Streams API交互，則專家組將需要打破大量API。 相反，如果不添加這些附加的實(shí)用程序方法（例如， 參見令人敬畏的新Map方法！ ），Java 8的性能將僅為其一半。

就是這樣。

即使也許更多的類構(gòu)建工具可能有用，但對(duì)于已經(jīng)做好很多事情來(lái)解決問(wèn)題的專家組來(lái)說(shuō)，它們也不是重點(diǎn)。 重點(diǎn)是為API演變提供一種方法。 或用Brian Goetz自己的話說(shuō)：

@breandan @lukaseder希望它能使一些人意識(shí)到“哎呀，這種語(yǔ)言設(shè)計(jì)的東西比我想象的要微妙得多”。

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

接觸社區(qū)

很好，Brian Goetz向社區(qū)伸出了援助之手，以幫助我們獲得有關(guān)Java 8的正確圖片。他沒有在私人消息中解釋有關(guān)專家組決策的理由，而是讓我在Stack Overflow上再次公開提問(wèn)（或lambda-dev），這樣他就可以公開回答他們了。 為了增加宣傳和更大的社區(qū)利益，我選擇了Stack Overflow。 這里是：

• Java 8接口方法中不允許“最終”的原因是什么？
• Java 8接口方法中不允許“同步”的原因是什么？

立刻獲得這兩個(gè)問(wèn)題的牽引力表明這些東西對(duì)社區(qū)有多么重要，因此請(qǐng)不要錯(cuò)過(guò)閱讀它們的機(jī)會(huì)！

但是很穩(wěn)定！

Java可能沒有node.js具有的“酷”的光環(huán)。 您可能會(huì)想使用JavaScript語(yǔ)言（只要它包含臟話），但是從平臺(tái)營(yíng)銷的角度來(lái)看，Java長(zhǎng)期以來(lái)一直是第一次受到挑戰(zhàn)–并且“不酷”并倒退-兼容無(wú)助于保持開發(fā)人員的興趣。

但是，讓我們從長(zhǎng)遠(yuǎn)考慮，而不是順應(yīng)潮流。 擁有如此出色的專業(yè)平臺(tái)，例如Java語(yǔ)言，JVM，JDK，JEE等，是無(wú)價(jià)的。 因?yàn)闅w根結(jié)底，“不可思議”的向后兼容性也可能很棒。 如前所述，我們已經(jīng)將集成測(cè)試升級(jí)到Java8。不是一個(gè)編譯錯(cuò)誤，也不是一個(gè)錯(cuò)誤。 使用Eclipse對(duì)Java 8的BETA支持 ，我可以輕松地將匿名類轉(zhuǎn)換為lambda，并編寫令人敬畏的東西，例如這些即將到來(lái)的jOOQ 3.4嵌套事務(wù)（API尚未最終實(shí)現(xiàn)）：

ctx.transaction(c1 -> {DSL.using(c1).insertInto(AUTHOR, AUTHOR.ID, AUTHOR.LAST_NAME).values(3, "Doe").execute();// Implicit savepoint heretry {DSL.using(c1).transaction(c2 -> {DSL.using(c2).update(AUTHOR).set(AUTHOR.FIRST_NAME, "John").where(AUTHOR.ID.eq(3)).execute();// Rollback to savepointthrow new MyRuntimeException("No");});}catch (MyRuntimeException ignore) {}return 42; });

因此，歸根結(jié)底，Java很棒。 Java 8是對(duì)以前版本的巨大改進(jìn)，并且在專家組中有很多人（并通過(guò)社交媒體與社區(qū)聯(lián)系），我相信Java 9會(huì)更好。 特別是，我期待了解這兩個(gè)項(xiàng)目的發(fā)展方式：

• 值類型
• 申報(bào)地點(diǎn)差異

盡管再次，我真的很好奇，他們將如何從向后兼容性的角度來(lái)實(shí)現(xiàn)這兩項(xiàng)改進(jìn)，以及之后需要了解哪些警告。

無(wú)論如何，我們希望專家組將繼續(xù)就Stack Overflow提供公眾反饋。

翻譯自: https://www.javacodegeeks.com/2014/05/java-8-friday-language-design-is-subtle.html

總結(jié)

以上是生活随笔為你收集整理的Java 8 Friday：语言设计很微妙的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。