I'm really grasping at straws here and asking for something
quantitative to substantiate this deprecation plan. As it stands,
there is hearsay and some stackoverflow links - surely going through
with this (and inflicting some level of pain on folks who don't care
for this) deserves something a bit better? Brian mentioned that one
criticism often heard is mistakes aren't corrected - I fully believe
that's true. But this may end up being one of those "they want to
correct mistakes and THIS is what they chose??!" things. I understand
the appeal in "correcting" this given it's a relatively new addition,
but I don't think it'll go over well.
On Tuesday, April 26, 2016, Paul Benedict <pbened...@apache.org
<mailto:pbened...@apache.org>> wrote:
Are you asking Brian to set up another survey monkey for the
masses? I expect a happy silent majority and a raucous
minority.... just based on past results. :-)
On Apr 26, 2016 6:38 PM, "Vitaly Davidovich" <vita...@gmail.com
<javascript:_e(%7B%7D,'cvml','vita...@gmail.com');>> wrote:
I've yet to hear one supporter on this thread besides yourself
and Stuart.
Is there some usability survey or something that actually
indicates a
significant sample of people don't like the name? Guava
Optional behaves
and is named the same way, and I've not heard anyone complain
about that (I
and many people I know used it for years).
I think the conversation would be *maybe* different if picking
a name for a
new thing, but the deprecation churn here adds no value, IMO,
and is going
to be viewed as an annoyance by a large swath of people.
On Tuesday, April 26, 2016, Brian Goetz
<brian.go...@oracle.com
<javascript:_e(%7B%7D,'cvml','brian.go...@oracle.com');>> wrote:
> As the person who chose the original (terrible) name, let me
weigh in...
>
> 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.
>
>
> On 4/26/2016 6:43 AM, Stephen Colebourne wrote:
>
>> In OpenGamma Strata we have 546 uses of Optional.get().
Renaming this
>> would be painful and add no value.
>>
>> While I understand the pain from some developers not
understanding the
>> feature, this is hardly unique in the world of Java.
Developers learn
>> the right way of doing something soon enough.
>>
>> And while
>>
>> if (opt.isPresent()) {
>> opt.get()
>> }
>>
>> is sometimes not ideal, in other cases it is the only
practical choice
>> (eg. where the method needs to have a return statement
inside the if
>> statement).
>>
>> Changing this to
>>
>> if (opt.isPresent()) {
>> opt.getWhenPresent()
>> }
>>
>> is just noise - I can see the "present" part twice.
>>
>> I just don't think I can support the rename (although many
of the
>> webrev tidy-ups are probably good).
>>
>> Stephen
>>
>>
>>
>> On 26 April 2016 at 00:05, Stuart Marks
<stuart.ma...@oracle.com
<javascript:_e(%7B%7D,'cvml','stuart.ma...@oracle.com');>> wrote:
>>
>>> 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/%7Esmarks/reviews/8140281/webrev.0.langtools/>
>>>
>>>
http://cr.openjdk.java.net/~smarks/reviews/8140281/webrev.0.jdk/
<http://cr.openjdk.java.net/%7Esmarks/reviews/8140281/webrev.0.jdk/>
>>>
>>> Thanks,
>>>
>>> s'marks
>>>
>>
>
--
Sent from my phone
--
Sent from my phone
