在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 8接口方法中不允許“最終”的原因是什么？
• Java 8接口方法中不允許“同步”的原因是什么？

立刻獲得這兩個問題的牽引力表明這些東西對社區有多么重要，因此請不要錯過閱讀它們的機會！

但是很穩定！

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 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; });

因此，歸根結底，Java很棒。 Java 8是對以前版本的巨大改進，并且在專家組中有很多人（并通過社交媒體與社區聯系），我相信Java 9會更好。 特別是，我期待了解這兩個項目的發展方式：

• 值類型
• 申報地點差異

盡管再次，我真的很好奇，他們將如何從向后兼容性的角度來實現這兩項改進，以及之后需要了解哪些警告。

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

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

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。