Optional require(s) NonNull

[Remi Forax]

First there is two Optionals, you have the common idea of 
Optional/Option, which is a way
to reified null as an Object and you have the one currently specified in 
the JDK which
doesn't allow null so in my opinion should not be call Optional/Option
but more ResultValue<T> or something like this, at least it will be more 
clear.

For Optional as usual, I don't think it's the right way to solve the 
problem of null,
I believe that @Nullable (with a package wide @NonNull qualifier) is 
better solution,
IntelliJ IDEA and Eclipse already support them and emit a warning or an 
error if
you forget to declare a nullable type @Nullable or use a potentially 
null reference.
In my opinion, the main issue currently of @Nullable/@NonNull is that 
these annotations
are not defined and used in the JDK.
Optional is the wrong answer, because it let users to think that having 
meaning full null,
null that represent a possible value and not an error is a good way to 
design software.

Like generics, that avoids CCE by not allowing to store anything in a 
collection,
the good way to solve null problem is to avoid to store null in a field 
or in a collection.

Rémi

On 10/30/2012 03:27 PM, Stephen Colebourne wrote:
> 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
>