Fwd: RFR(m): 8140281 deprecate Optional.get()
forax at univ-mlv.fr
Tue Apr 26 09:13:26 UTC 2016
I agree with Jon, Vitaly and Ali,
get is good candidate to @Bikeshed not for @Deprecated.
Le 26 avril 2016 08:26:43 CEST, Ali Ebrahimi <ali.ebrahimi1781 at gmail.com> a écrit :
>I agree with Jon, Vitaly,
>I think the name Optional completely describe its intents and semantics
>I don't think we need more descriptive method name here.
>Optional === may be have value
>Optional.get === may be return value
>Therefore, I think this all effort doesn't add any (or enough) value,
>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:
>> 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
>> 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:
>>>> It's pretty ugly that the recommended usage is to have to add a
>>>> 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
>>> 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
>>> current get() call. This is called for if lambdas should be avoided
>>> 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
>>> libraries (JDK 8) and getWhenPresent() doesn't exist in those. It
>>> generate a warning though. But as you explained to me the other day,
>>> code is later recompiled against the JDK 9 libraries, and in that
>>> does generate the warning.
>>> So for this case I think calling get() with @SuppressWarnings is the
>>> to proceed. I opted to extract a local variable and put @SW on it,
>>> to minimize its scope, but if you prefer an alternative I'd be happy
>>> change it.
More information about the core-libs-dev