java.util.Optional fields

[Remi Forax]

On 09/21/2012 06:02 PM, Vitaly Davidovich wrote:
>
> They're complementary, one doesn't replace the other.  If I'm looking 
> at a diff of a change outside of IDE, I'd like to have more context.  
> I also may not want to pollute my code with @Nullable all over the place.
>

I like the @NotNull by default option exactly for that, if you stupidly 
allow null everywhere,
you ends up with having to annotate your code with @Nullable all over 
the place.
It's a great way to learn how to confine null where it's only necessary.

Now, to come back to Optional, Java has not a really good way to 
currently deal with null,
Stephen Colebourne run several polls in 2009 [1] that shows that.
The real question is does Optional is the good answer.

There are several issues with Optional:
   - it introduces a cost at runtime (see one of my previous post that 
explain why the
     VM will not remove it) that makes it useless as return value of 
map.get() by example.
     So it's only a solution where the cost of creating an object is 
hidden by the cost
     of doing the calculation in the loop.
   - Optional should implements all methods and do nothing,
     By example, users will want Optional to implement Iterable by 
example to be able
     use Optional in a for-each, or implements Comparable, etc.
     Conceptually, Optional is a kind of kitchen sink but the type 
system of Java will see it
     as an ordinary object. The last time we chose a similar idea, it 
was when we decide
     to do the boxing using plain old Java classes instead of using type 
known by the type system.
     As a result, we can't use primitive type in generics.
   - If Optional is introduced in java.util, we will see types like 
List<Optional<T>>, i.e. types
     that embody Optional, something you don't want with @NotNull.

I might be wrong, but for me Optional doesn't worth the pain it will 
introduce.

Rémi
[1] 
http://blog.joda.org/2009/01/jdk-7-language-changes-everyone-votes_4547.html

> Sent from my phone
>
> On Sep 21, 2012 11:55 AM, "Remi Forax" <forax at univ-mlv.fr 
> <mailto:forax at univ-mlv.fr>> wrote:
>
>     On 09/21/2012 05:46 PM, Vitaly Davidovich wrote:
>     > The main benefit of Optional, to me, is that it clearly tells
>     the caller or
>     > receiver that this thing may be null; the conventional way is to
>     document
>     > pre/post conditions, but developers are notorious for not
>     reading docs.
>     > Returning/taking Optional is "in your face" - the fluent API is
>     a secondary
>     > convenience/benefit.
>
>     Any decent IDEs (at least Eclipse and IDEA) understand
>     @NonNull/@Nullable
>     and can be easily configured to not compile if you try to call a
>     method on
>     something that is @Nullable.
>
>     Are you suggesting that Optional is a runtime solution to a static
>     analysis problem ?
>
>     Rémi
>
>     >
>     > Sent from my phone
>     > On Sep 21, 2012 11:42 AM, "Zhong Yu" <zhong.j.yu at gmail.com
>     <mailto:zhong.j.yu at gmail.com>> wrote:
>     >
>     >> aren't all reference types in Java "optional" already? If
>     "fluent" API
>     >> is desired, is it possible to add methods to the null type?
>     >>
>     >> Zhong
>     >>
>     >>
>
>