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

[Jonathan Gibbons]

So, pop quiz, one question:

How many folk use the javac options -Xlint -Werror, and would thus see 
changes like this as a breaking change in the API?

-- Jon




On 04/26/2016 02:13 AM, Rémi Forax wrote:
> 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
>>>>
>>>