Nulls

[Brian Goetz]

Which is not wonderful, but not unlike the current status quo with 
collections, where the general contract may allow nulls, but the 
individual collections may or may not.  Any library method that lets you 
pass in a collection now has to make the conservative assumptions that 
(a) you might read nulls from it and (b) you can't write nulls to it.

Nulls are a big problem, and this approach does not solve them or even 
make it any better.  Arguably it makes it a little worse, in that the 
surface area of the existing problem expands slightly, but is it 
qualitatively worse than the status quo?

There's no good answer here.  The alternatives are all some form of:
  - Ban nulls
  - Distort the API to try and accomodate nulls
  - Maintain the status quo of benign neglect

I could go for the first but the path we're trying to chart here seems 
less heavy-handed?

On 9/26/2012 9:18 AM, Doug Lea wrote:
>
> On 09/25/12 10:48, Brian Goetz wrote:
>> null-aware as much as simply null-inappropriate -- i.e., don't use
>> this method
>> if you have nulls in your streams -- which means that the user does
>> has to be
>> null-aware.  Which I think is your point -- the user has to reason
>> about it.
>
> Yes. If the base framework kicks the nullness problem to its users,
> then every user must deal with it. But many of the "users" of java.util
> are not applications programs, but other utilities and frameworks that
> do not know whether the issues apply or not.
>
>>>    boolean present;
>>>    T x;
>>>    try {
>>>         Optional<T> r = ...findAny(...);
>>>         if (present = r.isPresent()) x = r.get();
>>>    } catch(NPE ex) {
>>>        present = true;
>>>        x = null;
>>>    }
>>>
>>> Not very nice.
>>
>> Or more nice:
>>
>>     ....filter(o -> o != null).findAny();
>
> No. If this is part of a utility as opposed to application program,
> then it doesn't know if nulls are allowed or not, so has to be
> correct in either case; or else advertise its policy as an
> unchecked precondition. Many people will not do either of these.
> This is the where most of the mistakes will appear.
> So in the likely event that you choose these rules anyway,
> it would be nice to at least alert the bug-detector folks
> to look for such constructions.
>
>
> -Doug
>