I agree with Jon, Vitaly and Ali, get is good candidate to @Bikeshed not for @Deprecated.
Rémi Le 26 avril 2016 08:26:43 CEST, Ali Ebrahimi <ali.ebrahimi1...@gmail.com> a écrit : >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 >>> >> >>
