Loose ends: Optional
jim at pentastich.org
Thu Jun 6 08:58:39 PDT 2013
>From the peanut gallery...
I've seen a lot of null pointer problems, particularly in code written by
less experienced developers. The null pointer problems are made worse
because it is often unclear where the null value originated. As a result,
we often adopt the null object pattern in new code, though that can be a
bit of a pain in Java since there is no shorthand for it. For that reason
alone I'm happy to see an Optional type.
Regarding the extra methods that have been generating the controversy, I
happen to like both the fluid and functional programming styles and would
definitely use those methods. I'm not as confident that our less
experienced developers would adopt them, but don't view that as a critical
problem. I have no direct experience with the Guava or Scala versions so
can't really comment there.
In a perfect world I might like to see a "one of" type for use in return
values, as that can be an excellent alternative to checked exceptions. In
that case, Optional could be interpreted as "oneof<T,Void>". Introducing
"one of" for the next Java release would be impractical, though it would be
nice if Optional could be defined in a way that did not preclude it later.
The other ability that I could wish for would be a way to associate an
empty Optional with a stack trace (possibly controlled by a system property
to avoid the overhead). I could have avoided many hours of quality time
with the debugger if I had a way to ask "what method returned this null
value". Again, probably too late at this point. Hopefully, though, there
will be a single source of empty Optional values so I can put a breakpoint
On Jun 5, 2013 7:53 PM, "Brian Goetz" <brian.goetz at oracle.com> wrote:
> Boy, it seems that one can't discuss Optional in any context without it
> generating hundreds of messages.
> Whatever we do here is a compromise between several poles whose proponents
> hold very strong opinions. There are those that really want Elvis instead;
> there are others who feel that a box-like class for Optional is a hack when
> it really should be part of the type system. Neither group is going to get
> what they want here; we can compromise and make everyone a little unhappy,
> or we can do nothing and make everyone unhappy (except that they will still
> hold out vain hope for their pet feature in the future.)
> This is made worse by the fact that many of those that have advocated for
> a Fugue-like interpretation of Optional (like Ben Huchinson) have behaved
> atrociously (which sadly is all too common among the neo-functional crowd).
> It is very hard to listen to someone whose approach is offensive and
> unreasonable and hear any of the merit in their argument. (Also, the first
> seven times this came around, it was simply the wrong time to discuss it --
> there were much bigger fish to fry, and choices made for Optional might
> have constrained the design space of higher-priority features, so it made
> sense to say "not now.")
> Sadly I am not optimistic that new and compelling observations will result
> from continued debate (though I would have liked for Kevin to share his
> opinions on-list.) At a meta-level, I'll observe that:
> - Those that have argued for these methods do so on the basis of having
> used them elsewhere and found them useful;
> - Those who have argued against them do not appear to have used them in
> anger, instead offering mostly FUD-like arguments such as possibility for
> user confusion or misuse or cost.
> So I have to give more credibility to the supporters than the detractors.
> There are lots of people who want this for reasons grounded in actual
> experience, and I'm inclined to let them have what they want (even if some
> of them asked extremely rudely.)
> I'm willing to hold this topic open for a few more days, to hear from
> those who have NOT already expressed a strong opinion.
> On Jun 4, 2013, at 3:28 PM, Remi Forax wrote:
> > On 06/04/2013 04:57 PM, Tim Peierls wrote:
> >> On Mon, Jun 3, 2013 at 10:54 PM, Joe Bowbeer <joe.bowbeer at gmail.com<mailto:
> joe.bowbeer at gmail.com>> wrote:
> >> Without the extra methods, the Java8 Optional is similar to
> >> Guava's. Fugue's Option is a more Scala-like replacement. There
> >> are a few succinct arguments in favor of the extra methods, such
> >> as those posted by Jed Wesley-Smith (Fugue) and Ben Hutchison
> >> (
> >> I would love to hear the Guava designers respond to Ben's charge
> >> of willful ignorance(!). I'm also wondering if the new methods
> >> added in more recent versions of Guava are addressing these
> >> deficiencies.
> >> The arguments in favor of the extra methods boil down to "Guava
> Optional looks a lot like something I see/use in Scala/Haskell/FP
> code/literature all the time, minus some methods. Therefore Guava Optional
> is deficient and Java 8 Optional should restore those methods."
> >> But Guava Optional is not trying to be any of the things its detractors
> want it to be. (I find Ben Hutchison's arrogant accusation of ignorance
> particularly galling.) It is only an alternative -- a better alternative --
> to the practice of using null to signify a missing value, especially a
> missing return value. Without it, users of an interface with methods that
> can return null to signify "no value" can -- and do, repeatedly -- forget
> to check for nullity and find out about their mistake only at runtime, if
> ever. With it, users are forced to at least acknowledge the need to check
> for a missing value. It can streamline the common cases of supplying a
> default value or, with Java 8 lambdas, an exception to throw when the value
> is missing.
> >> Detractors of a different stripe don't want Optional at all because it
> imposes overhead (in the code and at runtime) for what they think of as a
> dubious virtue. "It's an extra layer of safety code that I don't need.
> > Did you consider that there is perhaps a better mechanism that give you
> the safety you want without the overhead you describe ?
> >> Why should I pay for the fallibility of others?" That's a reasonable
> concern in the abstract, but if Optional is primarily used at the end of
> stream-y computations that might or might not return a value, the already
> tiny overhead in practice is going to be dominated by the stream machinery.
> > yes, if Optional is only used at the ends of a Stream.
> >> But, alas, I haven't had enough experience with Guava's Optional
> >> to form an opinion and I've had no experience with Fugue. I have
> >> had experience with Scala's Option and it seems to work pretty
> >> well, but we decided earlier to opt for a more limited approach.
> >> I have no practical experience of Scala Option or Fugue; I've only
> looked at documentation. I use Guava Optional both as a client of Guava
> methods and when defining my own APIs. It has saved my bacon many times and
> made my code more readable. When working with legacy APIs that still use
> null to represent missing values, I use things like Optional.fromNullable
> (to go from legacy to my code) and Optional.orNull() (to go from my code to
> legacy code).
> > Yes, that's my conclusion too, Optional without fromNullable is useless
> for representing something that can be null.
> >> I try to use Optional purely as a return type, and I try to avoid using
> monstrosities like List<Optional<Foo>> (or worse) in an API. I confess that
> in my first flush of excitement at having Optional, I went way overboard
> and did, in fact, create some truly horrible method signatures, but the
> crime conveys its own punishment, and I quickly learned what not to do.
> > Again there are ways to force Optional to be used only as a return type
> and not in middle of angle brackets.
> >> For at least one of the few use cases cited in favor of the extra
> >> methods, the Elvis operator produces the most readable results...
> >> Is Elvis an Option?
> >> I expect not.
> > Why ?
> >> --tim
> > Ok, there is a problem in the way Java uses null, this leads to a lot of
> NPEs, especially in rookie's code.
> > Before saying that Optional will save our world, we have already
> followed this kind of path, when we have decided
> > that there was a lot of ClassCastException and introduces generics.
> Given that we end up with half-baked generics
> > (reification is not the sole issue), I really think that we should take
> the time to explore, if it's a real issue or not,
> > what are scenarios we want to solve and how to solve it.
> > So instead to trying to commit ourselves to pattern like
> Optional/Option/Maybe which is basically a kind of boxing,
> > something we are now trying hard to remove (at least from the VM
> > I think it worth to explore the different alternatives.
> > Given we have no time to do that for 8, I think we should keep a simple
> Optional and
> > not commit ourselves to a specific pattern that tries to solve the NPE
> problem in Java using Optional.
> > Rémi
More information about the lambda-libs-spec-observers