看來可能是一種新的方法，將可在java.util.streams.Collectors類JDK 12即會，根據新方法的提出了基于Javadoc的文檔，“返回一個收藏家是將輸入的元素兩個規定的收藏家并將其結果與指定的合并功能合并?！?目前 ，此新Collectors方法的建議名稱為pairing ，但該新方法的名稱已成為重要討論的來源。

此方法的名稱引起了OpenJDK core-libs-dev郵件列表的廣泛討論。 盡管起初想將其標記為自行車脫落的示例（或帕金森氏平凡定律 ）很容易，但是我的經驗是，正確的命名比最初看起來更重要。 我已經看到很多情況下，特定實現的邏輯都沒有錯，但是隨之而來的問題是由于溝通不暢或與命名較差的代碼構造相關的錯誤假設而導致的與該實現的使用有關。 對于JDK中的主要API，畢竟如此認真地考慮此方法參數的名稱并不奇怪。

討論始于Peter Levart的帖子“ BiCollector ”（6月17日），他在開始時提出了一個問題：“您是否曾經想使用兩個Collector將同一Stream收集到兩個不同的目標中？” Levart提供了一個實現此類“ BiCollector ”的示例，并詢問這是否是可以添加到JDK中的東西類型。 毫不奇怪，事實證明這是其他人所期望的，并且提到了一些替代的現有實現（ Kirk Pepperdine和Tagir Valeev的streamex 實現 ）。

在討論了“ BiCollector”的多種實現方式之后， Tagir Valeev創建了一個OpenJDK“ 我自己的實現方式的初步Webrev ”， 并將其發布以進行審核 （6月15日）。 在那篇文章中 ，Valeev特別指出他為該方法編了“ pairing”（配對）的名稱，并補充說：“由于我不是英語母語人士，所以我無法判斷它是否是最佳選擇，因此歡迎更好的主意?！?那就是“ 打開了水閘 ！”

盡管圍繞擬議的“ BiCollector”的其他實現細節進行了一些有趣且有意義的討論（現在在擬議的代碼中為“ Collectors.pairing（…）”），但該方法的命名貢獻最大。在6月21日的帖子中 ，Valeev總結了提議的名稱，并附有關于每個建議的評論，我在此處復制了該列表（但沒有深刻的評論）：

• 平分
• 開球或開球
• 雙工
• 分叉 （或分叉？）
• 復制者
• 復制
• 扇出或扇出
• 分布
• 竊聽
• 分裂
• 解壓縮
• biMapping
• 二者皆是
• collectionToBothAndThen
• 收集雙方
• collectionTo
• 雙向收集
• 擴大
• 分叉

對于那些對上述提議的名稱“贊成”和“反對”的論點感興趣的人，我建議查看Valeev的原始帖子 。 上面鏈接的大多數帶有名稱建議的帖子都為其首選名稱提供了論據，并且對OpenJDK貢獻者認為方法名稱中的哪些方面可能有助于或阻礙對該方法的理解有一些有趣的見解。

在為該方法命名后，討論就此添加到Collectors API上了一段時間，直到Valeev今天發布了“ ping消息 ”，并鏈接到最新的webrev以供審核（將@since 11更改為@since 12 ）。 響應此“ ping”消息， 收到有關所建議方法的最后一個參數名稱 （當前稱為“ finisher ”）的反饋 ，這再次提醒了命名對于我們許多人的重要性。

在core-libs-dev郵件列表上有關此主題的其他文章提醒我們，要將這種新方法添加到Collectors 公共API中 ，仍然需要做一些事情，包括發起人自愿檢查和贊助更改集 。以及對CSR （ 兼容性和規范審查 ）的需求和“ 幾個完全了解Streams設計的審查者 ”。

Brian Goetz在此線程上的帖子總結了為什么命名此提議的方法如此困難：

在這里命名的基本挑戰是，該收集器要做兩件事（或可能三件事）：將流復制為兩個相同的流（“ tee”），將每個元素發送給兩個收集器（“ collecting”），然后合并結果（“精加工”）。 因此，所有的單字名稱（配對，發球，解壓縮，biMapping）僅強調操作的一半，而準確地捕獲整個工作流程的名稱（teeingAndCollectingAndThen）則很笨拙。

戈茨（Goetz ）的同一篇文章也反對該方法名稱的“合并”（或其派生詞），因為“沿'合并'的名稱可能會錯誤地給出合并是按元素進行的想法，而不是復制流，進行收集和合并”結果?！?

我發現一些建議的方法名稱是合理的，但是我相信（希望）有一些是出于幽默的嘗試。

JDK-8205461 [“合并其他兩個收集器的結果的創建收集器”]是描述此問題的“增強”“錯誤”。 目前，它的描述開始于“將新的Collector添加到Collectors類中，以合并其他兩個Collector的結果”，然后明確指出“應添加一個API方法（名稱尚待討論）”。 如果您曾經想在公共JDK API中命名方法，那么這可能是您的機會！

我已使用此博客文章來嘗試完成兩件事：

從JDK 12開始，使人們意識到這種方法很可能在公共API中可用

舉例說明命名為何如此重要以及為什么命名可能與技術實施一樣困難

• 對于任何人來說，正確的命名都可能會很困難，即使我們中的母語是英語的人也是如此！

盡管實現中的一個或多個名稱可能會更改，但是從邏輯上講 ， 當前提出的實現很可能與最終將與JDK-8205461結合交付的實現非常接近。

翻譯自: https://www.javacodegeeks.com/2018/08/jdk-12-merging-collectors.html

總結

以上是生活随笔為你收集整理的JDK 12，合并的收集器和命名的挑战的全部內容，希望文章能夠幫你解決所遇到的問題。

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