So, pop quiz, one question:
How many folk use the javac options -Xlint -Werror, and would thus see
changes like this as a breaking change in the API?
-- Jon
On 04/26/2016 02:13 AM, Rémi Forax wrote:
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
