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

Ali Ebrahimi ali.ebrahimi1781 at gmail.com
Tue Apr 26 06:26:43 UTC 2016

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

More information about the compiler-dev mailing list