Fwd: RFR(m): 8140281 deprecate Optional.get()
jonathan.gibbons at oracle.com
Mon Apr 25 23:43:58 UTC 2016
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.
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 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
> 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.
More information about the compiler-dev