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

[Rémi Forax]

I agree with Jon, Vitaly and Ali,
get is good candidate to @Bikeshed not for @Deprecated.

Rémi


Le 26 avril 2016 08:26:43 CEST, Ali Ebrahimi <ali.ebrahimi1781 at gmail.com> a écrit :
>Hi,
>I agree with Jon, Vitaly,
>I think the name Optional completely describe its intents and semantics
>so
>I don't think we need more descriptive method name here.
>Optional === may be have value
>So
>Optional.get === may be return value
>
>Therefore, I think this all effort doesn't add any (or enough) value,
>So
>isn't worth of it (from resource POV).
>Done side: The all current source codes that uses this method when
>compiling with java9 get dozen of warnings.
>
>On Tue, Apr 26, 2016 at 4:13 AM, Jonathan Gibbons <
>jonathan.gibbons at oracle.com> wrote:
>
>> OK.
>>
>> The best I can say is that I disagree with the underlying change (to
>> deprecate Optional.get) but that if the API change is generally
>agreed to,
>> then I reluctantly agree with the edit here.
>>
>> The bug needs a noreg-label.
>>
>> -- jon
>>
>>
>>
>>
>> On 04/25/2016 04:37 PM, Stuart Marks wrote:
>>
>>>
>>>
>>> On 4/25/16 4:27 PM, Jonathan Gibbons wrote:
>>>
>>>> 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?
>>>>
>>>
>>> Ah, I had neglected to explain this one, sorry.
>>>
>>> In the majority cases, uses of get() can be refactored away to use
>one of
>>> the other Optional methods.
>>>
>>> In just about all the remaining cases, the code should use the
>>> replacement method getWhenPresent(), which has the same semantics as
>the
>>> current get() call. This is called for if lambdas should be avoided
>because
>>> of startup performance, or because of checked exceptions, or if it's
>>> provable from context that a value is always present.
>>>
>>> The case of Enter.java is a special one; it gets compiled with the
>boot
>>> libraries (JDK 8) and getWhenPresent() doesn't exist in those. It
>doesn't
>>> generate a warning though. But as you explained to me the other day,
>this
>>> code is later recompiled against the JDK 9 libraries, and in that
>case it
>>> does generate the warning.
>>>
>>> So for this case I think calling get() with @SuppressWarnings is the
>way
>>> to proceed. I opted to extract a local variable and put @SW on it,
>in order
>>> to minimize its scope, but if you prefer an alternative I'd be happy
>to
>>> change it.
>>>
>>> s'marks
>>>
>>
>>