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

[Jonathan Gibbons]

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