为什么Java8中没有可选的.mapToInt()?

为什么Java8中没有可选的.mapToInt()?,java,java-8,java-stream,optional,Java,Java 8,Java Stream,Optional,在Java8 streams中,我可以使用mapToInt方法创建IntStream,对于某些操作(如findFirst),它将返回Optionants。为什么可选中没有类似的内容 int i = Stream .of("1") // just as an example .mapToInt(Integer::parseInt) // mapToInt exists for streams .findFirst() // this even ret

在Java8 streams中,我可以使用
mapToInt
方法创建
IntStream
,对于某些操作(如
findFirst
),它将返回
Optionant
s。为什么
可选
中没有类似的内容

int i = Stream
        .of("1") // just as an example
        .mapToInt(Integer::parseInt) // mapToInt exists for streams
        .findFirst() // this even returns an OptionalInt!
        .getAsInt(); // quite handy

int j = Optional
        .of("1") // same example
        .map(Integer::parseInt) // no mapToInt available
        .get().intValue(); // not as handy as for streams

显然,Java-9中的选项中会出现一些附加方法。但是,不太可能添加
mapToInt
。几天前,我在core-libs-dev中提到了这个问题。以下是Paul Sandoz:

我不想去那里,我的回答是把
可选的*
转换成
*流
。添加
mapOrElseGet
(注意,原语变体返回
U
)的一个参数是,其他功能可以由它组成

以及:

我认为用Optional污染optionant等是可以的,但我想从另一个方向避免它


总的来说,我认为这是合理的。基元流的目的是在处理多个基元值时提高性能。然而,对于
Optional
来说,使用原语值的性能增益非常小(如果有的话)(与通过JIT编译器优化的额外装箱流相比,有更大的机会)。此外,尽管project不会出现在Java-9中,但它正在逐渐向前发展,而且在Java-10中,我们可能最终会看到泛型而不是原语,因此这些原语选项将变得完全不必要。在这种情况下,在对象
Optional
和基元
OptionalInt
之间添加更多的互操作性似乎是不必要的。

API中进行专门化是有意义的,因为流可能代表处理数百万元素的批量操作,因此性能影响可能是巨大的。但据我所知,即使是这个决定也并非没有争议

对于一个
可选的
,最多包含一个元素,性能影响并不能证明需要额外的API(如果有影响的话)。现在还不太清楚,
optionant
等是否真的有必要

关于方便,我不能理解你的意思。以下工作:

int j = Optional.of("1").map(Integer::parseInt).get();
您的建议是添加另一个API,允许将上述语句重写为

int j = Optional.of("1").mapToInt(Integer::parseInt).getAsInt();
我不认为这会增加便利性

但是按照逻辑,使用Java9,您可以编写

int j = Optional.of("1").stream().mapToInt(Integer::parseInt).findFirst().getAsInt();

这更增加了这种“便利性”…

以下功能也非常有效:

int j=可选
。of(“1”)
.map(整数::parseInt)
.map(optionant::of)/->可选
.orElse(optionant.empty())/->optionant
.getAsInt();
诀窍是将
Optional
映射到
Optional
,然后打开内部
OptionalInt
。因此,就
可选
而言,不涉及原语
int
,因此它适用于Java泛型

这种方法的一个优点是它不需要自动装箱。这对我来说很重要,因为我们在项目中启用了自动装箱警告,主要是为了防止不必要的装箱和拆箱操作

我在实现一个公共方法时偶然发现了这个问题和解决方案,该方法返回一个
OptionalInt
,其中实现使用另一个返回
Optional
的方法。 我不想从我的公共方法返回
Optional
,所以我搜索了类似
Optional.mapToInt
的内容,就像你一样


但是在阅读了Holger和Tagir Valeev的回答后,我同意在JDK中省略这样一种方法是完全合理的。有足够多的可选方法。

这是Brian Goetz的一句话:“请求添加到Optional的“明显”方法集似乎是无限的”。因为
optionant
和其他特例方法的存在只是为了避免许多装箱/拆箱操作。为什么
.getAsInt()
.get().intValue()
好得多?简单地调用
get()
,省略过时的
intValue()
调用怎么样?