java.util.Optional fields

Vitaly Davidovich vitalyd at
Fri Sep 21 10:03:41 PDT 2012

I agree about Optional not being an option where allocations are
undesirable - this is part of the reason where SA via @Nullable is
complementary rather than replacement.

I don't get the part about having to implement Iterable.  Why can't you
write some_nullable.or(Collections.emptyList()) as an example, assuming its
storing something that's Iterable? For Comparable, you'd return some Null
object that makes sense to compare if the scenario allows for it.

I don't think it has to be a kitchen sink - quite the opposite actually.
Nor would you use it everywhere as that most likely indicates poor design,
as you say.

Sent from my phone
On Sep 21, 2012 12:37 PM, "Remi Forax" <forax at> wrote:

> 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]**jdk-7-language-changes-**
> everyone-votes_4547.html<>
>  Sent from my phone
>> On Sep 21, 2012 11:55 AM, "Remi Forax" <forax at <mailto:
>> forax at>> 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
>>     <mailto:zhong.j.yu at>> 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
>>     >>
>>     >>

More information about the lambda-dev mailing list