Why is there no Optional.mapToInt() in Java8?

Question

In Java8 streams I can use the mapToInt method to create an IntStream, which will return OptionalInts for some actions (like findFirst). Why isn't there anything similar in Optional?

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

Answer 1

Apparently a handful of additional methods will appear in Optionals in Java-9. However it's unlikely that mapToInt will be added. I discussed this problem several days before in core-libs-dev. Here's Paul Sandoz answer:

I don’t wanna go there, my response is transform Optional* into a *Stream. An argument for adding mapOrElseGet (notice that the primitive variants return U) is that other functionality can be composed from it.

And later:

I think it’s fine to to pollute OptionalInt etc with Optional but i want to avoid it for the other direction.

In general I think it's reasonable. The purpose of primitive streams is to improve the performance when you process many primitive values. However for Optional the performance gain of using the primitive value is quite marginal if any (there are much bigger chances compared to streams that extra boxing will by optimized out by JIT-compiler). Also even though project Valhalla will not appear in Java-9, it's gradually moving forward and it's possible that in Java-10 we will finally see generics-over-primitives, so these primitive optionals will become completely unnecessary. In this context adding more interoperability between Object Optional and primitive OptionalInt seems unnecessary.

Answer 2

It makes sense to have specializations in the Stream API as a stream may represent bulk operations processing millions of elements, thus the performance impact can be dramatic. But as far as I know, even this decision wasn’t without a controversy.

For an Optional, carrying at most one element, the performance impact is not justifying additional APIs (if there ever is an impact). It’s not quite clear whether OptionalInt, etc. are really necessary at all.

Regarding the convenience, I can’t get your point. The following works:

int j = Optional.of("1").map(Integer::parseInt).get();

your proposal is to add another API which allows to rewrite the above statement as

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

I don’t see how this raises the convenience…

But following the logic, with Java 9, you can write

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

which raises this kind of “convenience” even more…