Java 8 是否缺少一个 OptionalBoolean？

这句话解释了拥有原始流背后的考虑因素。我假设这同样适用于原始的可选。简而言之，原始流（可能还有可选流）是出于性能原因而创建的。他们没有为所有8种基元类型创建它们，以减少代码重复和接口污染。

引用Brian Goetz在lambda邮件列表中的话：

更一般地说：拥有专门的原始流（例如，IntStream）背后的哲学充满了令人讨厌的权衡。一方面，它有很多丑陋的代码重复，接口污染等。另一方面，任何一种关于盒装运算的算术都很糟糕，并且没有减少整数的故事将是可怕的。因此，我们处于一个艰难的角落，我们试图不让它变得更糟。

不让它变得更糟的诀窍#1是：我们没有做所有八个基元类型。我们正在做int，long和double;所有其他的都可以通过这些来模拟。可以说，我们也可以摆脱int，但我们认为大多数Java开发人员还没有准备好。是的，会有对角色的呼唤，答案是“把它贴在一个int中”。（每个特化都投影到 JRE 足迹约 100K。

诀窍#2是：我们使用原始流来公开在原始域中最好完成的事情（排序，缩减），而不是尝试复制您在盒装域中可以做的所有事情。例如，没有IntStream.into（），正如Aleksey指出的那样。（如果有，下一个问题是“IntCollection在哪里？IntArrayList？IntConcurrentSkipListMap？）目的是许多流可能从参考流开始，最终成为原始流，但反之亦然。没关系，这减少了所需的转换次数（例如，int -> T 没有映射的重载，int -> T 没有函数的特化，等等。

我应该提到，我在这个问题的答案中找到了这句话。

boolean值经常被滥用为参数。有效的 Java 第 2 版警告不要滥用布尔值。如果不是实际的布尔真/假参数，它们通常会导致可读性差的代码。相反，作家约书亚·布洛赫（Joshua Bloch）试图说服人们使用双值：enum

首选双元素枚举类型而不是布尔参数。它使代码更易于阅读和编写，尤其是在使用支持自动完成的 IDE 时。此外，它还可以使以后轻松添加更多选项。

大多数实例可能会被错误地使用。这是不包括在内的一个很好的理由。但我不能说 - 只有甲骨文可以 - 如果这就是它不在那里的原因。OptionalBoolean