RFR(m): 8140281 deprecate Optional.get()

[Stuart Marks]

On 4/26/16 9:20 PM, Kevin Bourrillion wrote:
> Guava owner here, and yes, I've never heard such a complaint about our
> Optional.get() method. This class has about a quarter of a million usages
> inside Google alone (I'm not kidding), and people seem quite happy with it.

Hi Kevin, thanks for your comments.

Interesting to hear yours (and Google's) experience with Guava's Optional.get(). 
How does Google avoid misusing it? Better programmers, better reviews, ability 
to refactor globally, or something else? Based on some of the code I've seen in 
the JDK and on grepcode.com (posted upthread), perhaps 50% or more of the uses 
of the JDK's Optional.get() are bad or suspect.

Usually issues like this can be mitigated with Stack Overflow answers, blog 
articles, conference talks, better documentation, etc. But when the rate of 
misuse is this high, maybe it means that there's something wrong with the API 
itself.

Now it may be the case that a particular proposal to fix the problem creates 
more pain than is worthwhile. I'm sympathetic to this, and I'm willing to 
discuss variations on or alternatives to proposals that reduce the pain. And I'm 
also prepared to accept, after exploring alternatives, that there might not be 
any that are sufficiently pain-free to proceed.

But I'm also hearing that "Optional.get() isn't a problem." I'm really surprised 
by this. After looking at a bunch of code that uses Optional.get() it really 
looks like a problem to me. But maybe somebody can explain to me why it isn't.

> We have been planning to migrate these usages from our Optional class to
> yours (sounds crazy, but this is how we roll). Threads like this one -- and
> the threat of changing Optional in-place incompatibly to become a value
> type as part of Valhalla -- are making us, for the first time, seriously
> question whether that is such a good idea.
>
> Please don't rename this method.

I'll set aside the issue of value types for this discussion.

We're not proposing to rename the method, strictly speaking. (I did use the word 
"rename" in my initial message on this thread. This was imprecise. If this 
misled anyone, I apologize.)

A rename is strictly the addition of method and the removal of the old one. This 
is source and binary incompatible. We're not proposing that.

We're also not proposing some temporary overlap of the old and the new for a few 
releases, after which the old would be removed. If we were to do that, we'd 
annotate the old method with @Deprecated(forRemoval=true). But the proposal is 
to deprecate with forRemoval=false (which is the default value, so it's elided).

Instead, the proposal is to deprecate the old method, adjust the documentation 
to refer to the new method (and other Optional methods) and to leave the old 
method there indefinitely. This changes the behavior of IDEs and the way 
compilers issue warning messages, but otherwise it's source and binary compatible.

Does this still make you reluctant to migrate to the JDK's Optional? If so, I'd 
like to understand this better, in order to improve the proposal.

s'marks