Fwd: RFR(m): 8140281 deprecate Optional.get()
Jonathan Gibbons
jonathan.gibbons at oracle.com
Mon Apr 25 23:27:41 UTC 2016
Enter.java:
It's pretty ugly that the recommended usage is to have to add a
SuppressWarnings for a reasonable and valid use of Optional.get.
Are you sure this is the API you want?
-- Jon
On 04/25/2016 04:14 PM, Stuart Marks wrote:
> One of the changes in the langtools webrev
>
> http://cr.openjdk.java.net/~smarks/reviews/8140281/webrev.0.langtools/
>
> is in the compiler. Please review.
>
> Thanks,
>
> s'marks
>
>
> -------- Forwarded Message --------
> Subject: RFR(m): 8140281 deprecate Optional.get()
> Date: Mon, 25 Apr 2016 16:05:13 -0700
> From: Stuart Marks <stuart.marks at oracle.com>
> To: core-libs-dev <core-libs-dev at openjdk.java.net>
>
> Hi all,
>
> Please review these webrevs that deprecate Optional.get() and to
> replace it with Optional.getWhenPresent(). The corresponding changes
> are also applied to OptionalDouble.getAsDouble(),
> OptionalInt.getAsInt(), and OptionalLong.getAsLong().
>
> Unlike most deprecations, this isn't about the function or the utility
> of some API, it's about the name. The solution is basically to rename
> the API. The problem is that "get" shows up as the "obvious" choice in
> things like IDE code completion, leading to code that mishandles empty
> Optionals. Typical Stack Overflow discourse runs something like this:
>
> Q: what do I do with this Optional thing
>
> A: just call get()
>
> Q: thanks, it works!
>
> Of course, it works until it doesn't.
>
> Examining the JDK's use of Optional.get(), I didn't see very many
> cases that called get() without first checking for the presence of a
> value. But I did see quite a number of cases like this:
>
> if (opt.isPresent()) {
> doSomething(opt.get());
> } else {
> doSomethingElse();
> }
>
> In many of these cases, the code could be refactored to use other
> Optional methods such as filter(), map(), or ifPresent().
>
> In any case this reinforces the contention that use of get() leads to
> poor code.
>
> For this changeset, in just about all cases I've simply replaced the
> call to get() with a call to getWhenPresent(). In a couple cases I
> replaced the stream calls
>
> .filter(Optional::isPresent).map(Optional::get)
>
> with
>
> .flatMap(Optional::stream)
>
> which I hope will become the new idiom for unwrapping a stream of
> Optionals.
>
> While many cases could be cleaned up further, I didn't change them.
> The reasons are that I didn't want to spend too much time putting code
> cleanup into the critical path of this changeset (I'd be happy to help
> later); doing so would create potential conflicts with code coming in
> from the Jigsaw forest; and there are non-obvious places where
> converting from a conditional to one of the lambda-based methods could
> cause performance problems at startup.
>
> There are also a few cases where simplification is prevented because
> it would end up causing the resulting lambda expressions to throw
> checked exceptions. :-(
>
> Webrevs here:
>
> http://cr.openjdk.java.net/~smarks/reviews/8140281/webrev.0.langtools/
>
> http://cr.openjdk.java.net/~smarks/reviews/8140281/webrev.0.jdk/
>
> Thanks,
>
> s'marks
More information about the compiler-dev
mailing list