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

[Ali Ebrahimi]

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
>>
>
>


-- 

Best Regards,
Ali Ebrahimi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20160426/6a74ae63/attachment-0001.html>