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

[Stephen Colebourne]

On 26 April 2016 at 22:55, Brian Goetz <brian.goetz at oracle.com> wrote:
> As the person who chose the original (terrible) name, let me weigh in...

We start from a different premise - I do not think that get() is a
terrible name. Nor was it the biggest API mistake in Java 8 (I've come
to believe parallelStream() was that).

FWIW, if I agreed that it was a terrible name, I would be in favour of
the rename at the earliest opportunity. How about Duration.getNano(
which should have been getNanos() ?

Kevin has already outlined the key reason for the name get() - that
Guava uses it and has done for many years. It is therefore the
accepted name for the method. More broadly, it is used in association
with isPresent() and as such seeing "getWhenPresent" repeats "present"
and is far too much in your face.

Ultimately, Optional is a class that requires a degree of learning.
That learning is not hard and will happen with time. Where things went
wrong IMO was adding Optional without tackling null-management in the
language, but thats a separate debate.

My experience is certainly not that 50% of users use it wrong. I do
accept that many will not use orElse() or map() when they should, but
that is fine - so long as they use isPresent() before get(), the rest
can come later.

To be clear, a lot of the claimed justification for this from Stuart's
earlier message is that people are using get() instead of orElse(),
orElseThrow(), filter(), map() etc. _but I don't care about that at
all_. Overuse of isPresent() is rife but fine. The only case that
matters is use of get() without any check.

On 27 April 2016 at 06:42, Stuart Marks <stuart.marks at oracle.com> wrote:
> Briefly, it strictly isn't a rename. The old method would be deprecated
> not-for-removal, and would be left in place indefinitely.
> Does this still create pain? If so, is there some way the proposal can be
> modified to reduce it?

We keep our code free of all deprecations. As such, this will require
change when we adopt Java 9. So, this is a rename in practical terms.
The replacement being significantly longer will also cause line-length
issues and reformatting in places.

TLDR, we view Optoinal as a new core API added in Java 8 that was have
relied on and used widely. It is fine as is, and does not need any
alteration.

Stephen



> I think calling this method "get()" was our biggest API mistake in Java 8.
> Now, one could argue that, if this is the biggest mistake we made, then we
> did pretty darn good.  Which may be true, but ... make no mistake, it was
> the wrong name (mea culpa), and experience has borne out that it is widely
> misused.  Subjectively, about half the uses of .get() I see are wrong -- and
> wrong in the obvious, avoidable way -- they don't consider the optional
> might be empty. So they've just traded an unexpected NPE for an unexpected
> NSEE.
>
> Its problem is, essentially: it looks harmless, but isn't, but it sure seems
> like the method you obviously want when you're browsing the autocomplete
> list / javadoc.  It's a hazard both to code writers (pick the wrong method
> because the name is bad) and to code readers (deceptively harmless looking.)
>
> Methods like orElse or ifPresent look harmless, and are; methods like
> orElseThrow have potentially harmful side-effects but have names that are
> transparent about what harm they could do.  But Optional.get() is neither
> safe nor transparent -- and yet awfully tempting-looking -- and this leads
> to frequent misuse.  Naming matters, and this one was wrong, and the harm is
> observable.  I wish I'd caught it before 8 shipped.
>
> Stepping back a bit ... one of the most frequent complaints we get is
> "mistakes never get fixed".  So, we've decided to be more serious about
> deprecation -- Dr. Deprecator is suiting up!  But that means, for any given
> item, some people are going to disagree about whether deprecation is
> suitable, and some will be inconvenienced by the deprecation -- this is
> unavoidable.
>
> Why prioritize this one?  In part, because it's a *new* mistake, and has had
> less time to become entrenched -- and this is the very first opportunity we
> have to fix it.  If we can't fix an API mistake at the very first
> opportunity, the logical consequence is we can't ever fix anything.  And
> that doesn't seem to be the world we want to retreat to.
>
> Similarly, is this the worst mistake in all of Java?  Surely not. But its
> also not reasonable to say "you can't fix X until you've fixed everything
> worse than X" -- again, that's a recipe for never fixing anything.  So, in
> the context of a deprecation effort, this seems an entirely reasonable
> candidate.
>
> I'd like to see it fixed, and the sooner the better.
>