java.util.Optional fields

[Sergey Kuksenko]

I think here we have two questions - the first is about nulls in streams 
and the second about Optional itself. For me is more interesting to 
clarify the first questions. Allow or don't allow null as element of Stream.

Current trend (implemented in Optional) is forbidding null in streams. 
So I'd like to ask what will we do with collections where null is 
accepted as element? How such collections should be converted to 
Streams? It is such collections as all non-primitive arrays, all 
java.util.Lists, HashMap end etc.



On 09/21/2012 08:25 PM, Peter Levart wrote:
> On 09/21/2012 05:20 PM, Kevin Bourrillion wrote:
>> On Fri, Sep 21, 2012 at 8:05 AM, Peter Levart <peter.levart at gmail.com
>> <mailto:peter.levart at gmail.com>> wrote:
>>
>>      The 3-state Optional (non-null value, null value, empty) has a benefit
>>      in that it can express the 3rd option in a way that does not force
>>      using
>>      exceptions.
>>
>>
>> That is correct.
>>
>> - A plain old T reference has only one kind of not-there: null.
>> - A Guava Optional<T> reference has two: null, and absent.
>> - The proposed Optional<T> has three: null, absent, and contains-null.
> I had the impression that an Optional<T> reference would never be null.
> You can not enforce that, but as Stream is currently implemented, it
> never returns null where the return type is Optional<T>.
>
> So in context of Stream(s) we have 4 choices:
>
> a) don't allow null as elements of Stream (throw NPE if such element
> encountered), the return type of .findFirst() is T and returns null if
> no such element exists
> b) don't allow null as elements of Stream (throw NPE if such element
> encountered), the return type of .findFirst() is Optional<T> and never
> returns null, but an empty Optional when no such element exists or
> non-empty optional when it exists.
> c) allow null as elements of Stream, the return type of .findFirst() is
> T and throws NoSuchElementException when no such element exists or
> returns the possibly null element if it exists.
> d) allow null as elements of Stream, the return type of .findFirst() is
> Optional<T> and never returns null, but and empty Optional<T> when no
> such element exists or an Optional with possibly null element if it exists.
>
> I thought that the intent was to do d), but it seems that as it is
> implemented, we have b).
>
> I guess it all boils down to whether we would allow null elements as
> elements of Stream or not.
>
> Regards, Peter
>
>> If this is an improvement, why not four?  Of course, that's
>> ridiculous.  So we're really suggesting that three is somehow the
>> magic number of logical kinds of "not-there" that should be enabled?
>>
>> And what of all the users who only wanted two?  One kind of not-there
>> will be represented as Optional.absent() for sure, but the other could
>> be either plain null or optional-containing-null, and neither approach
>> is obviously better than the other, so users will probably end up
>> using a mixture.
>>
>> Result: proper usage of this Optional will really depend on JSR-308
>> annotations.  To get the behavior Guava gives them today, users will
>> need to use Optional<@Nonnull T>.
> or better @Nonnull Optional<T> ...
>
>> Guava's been getting along fine with its Optional that can't hold
>> null. When users have three kinds of not-there, we suggest that
>> they're /really/ better off making their own type that actually
>> defines what each of these is really supposed to /mean/ more clearly.
>>
> Do users of Guava pass null values where Optional is expected?
>
> Regards, Peter
>
>
>


-- 
Best regards,
Sergey Kuksenko