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.gibb...@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