RFR(s): 8140281 add no-arg Optional.orElseThrow() as preferred alternative to get()
stuart.marks at oracle.com
Sat Dec 9 00:00:06 UTC 2017
Please, let's not derail this thread. :-)
I think would be a good thing to think about, so I've filed a JIRA issue to
On 12/8/17 1:45 AM, Remi Forax wrote:
> Let's gently derail this thread, the is another pain point with the current optional API,
> it seems that are no simple way to transform an Optional<Integer> to an OptionalInt and vice-versa.
> It's painful because we start to see interface that returns by example OptionalInt while the implementation you want to connect with return an Optional<Integer>.
> The only workaround seems to be to use a Stream/IntStream:
> Optional -> OptionalInt
> optional.stream().mapToInt(x -> x).findFirst()
> OptionalInt -> Optional
> I think, Optional should have the method mapTo*/flatMapTo* and Optional[Primitive] the method boxed().
> ----- Mail original -----
>> De: "Stuart Marks" <stuart.marks at oracle.com>
>> À: "core-libs-dev" <core-libs-dev at openjdk.java.net>
>> Envoyé: Vendredi 8 Décembre 2017 01:33:41
>> Objet: RFR(s): 8140281 add no-arg Optional.orElseThrow() as preferred alternative to get()
>> Hi all,
>> Please review this changeset that introduces a new no-arg method orElseThrow()
>> to Optional, as a preferred alternative to the get() method.
>> Corresponding methods are also added to OptionalDouble, Int, and Long.
>> The orElseThrow() method is functionally identical to get(). It has some
>> affinity with the existing orElseThrow(exceptionSupplier) method, being
>> equivalent to orElseThrow(NoSuchElementException::new).
>> The get() method is functionally unchanged. It is NOT being deprecated, although
>> some wording in the doc has been added to point to orElseThrow() as the
>> "preferred alternative." This is part of a (slow) migration away from
>> Optional.get(), which has an obvious, attractive name that is often misused.
>> These issues have been discussed on this list previously:
>> Please note that much of that discussion was about the then-proposed deprecation
>> of Optional.get(), which is NOT part of this proposal. There are no plans to
>> deprecate Optional.get() at this time. This proposal ONLY introduces a new
>> method orElseThrow() that is identical in function to get().
>> Bug report:
More information about the core-libs-dev