"I think our first time Optional use error rate is near 100%."
First, I am using "error" broadly here to include non-optimal usages, all
but one inappropriate usage was guarded with isPresent.
Second, these cases all occurred on the developer's initial encounter with
Optional (and with functional programming in Java).
After initial reviews developers began to use Optional as it was intended
and when they felt the need to use isPresent and/or get() they would consult
a colleague before proceeding.
Why do developers make these mistakes?
As others have said it is the "obvious" choice when following code
completion driven development ("It has a short familiar name, it takes no
arguments, the javadoc says it throws an exception but it's unchecked, and
it returns the thing I want, that must be what they intend for me to use!").
Further, I think that many devs are unfamiliar with programming in a
functional style to begin with and when they encounter methods that take
Suppliers, Consumers, and Functions they will instinctively avoid them in
favor of good old get().
Unlike some on the list, I do believe developers read the javadoc, as
unguarded get() usages are rare, but they only read the method level javadoc
they receive via code completion.
If the javadoc on the get() method was more explicit about proper usage this
would likely reduce improper usage.
In fact maybe this is why the Google team reports few improper usages with
Guava's Optional as its get() javadoc (since at least r11) reads "If the
instance might be absent, use {@link #or(Object)} or {@link #orNull}
instead.".
Is more opinionated javadoc the answer? Maybe, but I think javadoc
improvements along with the deprecation and a less seductively named
alternative would help a significant amount more than javadoc improvements
alone.
--
View this message in context:
http://openjdk.5641.n7.nabble.com/RFR-m-8140281-deprecate-Optional-get-tp268177p269209.html
Sent from the OpenJDK Core Libraries mailing list archive at Nabble.com.
