Optional require(s) NonNull

[Roland Tepp]

Stephen, I think if Optional type is there, it is going to be used in all
sorts of creative and occasionally stupid ways (creating a list of
optionals qualifies for me as stupid use of Optional).

I am not so much concerned about how or where people start using it (this
will settle eventually by best practices) as much as I am concerned that
the Optional type in Java SDK will not deliver on the promise people who
are familiar with the concept are expecting it to deliver:
* Null safety and declarative optionality of return types (or any such
"unsafe" input)
* Functional patterns traversing and transforming values inside an optional
value (ie transform, forEach, flatMap, etc.), that allow creating rich
almost declarative workflows operating on optional/unsafe input. In my
humble opinion much easier to read than a jungle of if-not-nulls that You
see all around the code today.

I understand, this is a matter of taste and style, but almost same
objections of readability and complexity were raised when generics were
introduced to Java.
People eventually learned to use and love them and if you ask an average
Java developer today, they'd probably want more of it (reified generics)
rather than going back to times before 1.5.


2012/10/30 Stephen Colebourne <scolebourne at joda.org>

> On 30 October 2012 13:48, Roland Tepp <luolong at gmail.com> wrote:
> > The whole point is to make the code safer from NPE's by throwing the
> > "optionality" of the value in your face and forcing you to deal with it
> > explicitly.
> >
> > So instead of writing code like this:
> >     String someString = ...
> >     if (someString == null) {
> >         someString = "some default string";
> >     }
> >     someString.split(...);
> >
> > you would write:
> >     Optional<String> optionalString = ...
> >     optionalString.orElse("some default string").split(...);
> >
> > Much cleaner and easier to understand imho and completely safe from
> > accidental NPE.
>
> What is important to understand is that Optional is a religious issue
> for many. As much as you believe that Optional is great and should be
> widely used everywhere, there are others, like myself, who believe
> that widespread use in Java would adversely affect the general
> readability of Java code, something which is Java's greatest asset.
>
> AFAICT, Optional is used Stream and only as the return type from 3
> methods. It is not used for input types and it is not used for things
> such as List<Optional<String>> or input parameters.
>
> To be clear, I believe that the language should provide support for
> null. For example, String defines a non-null variable, whereas String?
> defines a nullable variable (this is implemented in a variety of other
> JVM languages).
>
> Given we don't have null support in the language, the use of optional
> in a return type is just about acceptable. However, polluting that
> type all over the place, into List<Optional<String>> or method
> arguments would be a big negative for me. The key issue is not the
> theoretical safety it brings, but the development team issues where
> one team uses Optional everywhere and another does not, requiring lots
> of copying/conversion of data as the two teams try to call each others
> APIs.
>
> As such, I encourage the class to be renamed to OptionalResult<T>.
> This expressly discourages the widespread misuse of optionals in
> scenarios where they should not be used, such as
> List<Optional<String>>, by indicating the correct usage from the
> naming.
>
> Stephen
>
>


-- 
Roland