看来可能是一种新的方法，将可在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中命名方法，那么这可能是您的机会！

我已使用此博客文章来尝试完成两件事：

1. 从JDK 12开始，使人们意识到这种方法很可能在公共API中可用
2. 举例说明命名为何如此重要以及为什么命名可能与技术实施一样困难
   • 对于任何人来说，正确的命名都可能会很困难，即使我们中的母语是英语的人也是如此！

尽管实现中的一个或多个名称可能会更改，但是从逻辑上讲 ， 当前提出的实现很可能与最终将与JDK-8205461结合交付的实现非常接近。

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