RFR 9: 8138963 : java.lang.Objects new method to default to non-null

[Roger Riggs]

Hi,

The primary purpose of the existing 'requireNonNull' methods is to check 
for null
and throw an exception. It is used for explicit testing and producing a 
cogent exception.
Returning the value was a secondary benefit that allowed it to be used 
in fluent expressions.

The purpose of the new methods is to provide a default value (non-null);
throwing an exception is secondary.  This is consistent with the 
behavior and intent
of the Optional methods.

So, I think using the more concise naming consistent with Optional is 
preferred
because it is more readable and usable.

New Methods:
- T nonNullElse(T,T) (cf. Optional::orElse)
- T nonNullElseGet(T,Supplier<T>) (cf. Optional::orElseGet)

The existing methods cover the cases for checking and throwing exceptions.
- T requireNonNull(T) (cf. Optional::get)
- T requireNonNull(T,String) (shorthand for common use of 
requireNonNullElseThrow)

Except for throwing some exception other than NPE, which is included in 
Optional.orElseThrow

- T requireNonNullElseThrow(T,Supplier<X>) (cf. Optional::orElseThrow)

Combines two different purposes and I don't think it pulls it own weight 
in the Objects case.
More general would be T requireNonNullThrow(T, Supplier<X>). (not proposed)

Roger

webrev:  http://cr.openjdk.java.net/~rriggs//webrev-object-non-null





On 10/9/2015 8:22 AM, Daniel Fuchs wrote:
> Hi Brian,
>
> On 09/10/15 13:41, Brian Goetz wrote:
>> The semantics of require* here was that it should throw if the 
>> precondition
>> is violated.  That lead to a different naming direction than the current
>> use case, in which null is an expected value rather than an error.
>
> Not necessarily - as the requireNonNull*(x, y) will throw if the
> resulting value would be null: the method either returns non-null
> or throws... In other words it throws if the postcondition
> is violated (which the existing require* method also do,
> since for those precondition and postcondition are the same).
>
> best regards,
>
> -- daniel
>
>>
>> Sent from my iPhone
>>
>>> On Oct 9, 2015, at 11:58 AM, Stephen Colebourne 
>>> <scolebourne at joda.org> wrote:
>>>
>>>> On 9 October 2015 at 01:31, John Rose <john.r.rose at oracle.com> wrote:
>>>> This leads me to yet another bikeshed color, FWIW:
>>>>
>>>> - T requireNonNull(T) (cf. Optional::get)
>>>> - T requireNonNullElse(T,T) (cf. Optional::orElse)
>>>> - T requireNonNullElseGet(T,Supplier<T>) (cf. Optional::orElseGet)
>>>> - T requireNonNullElseThrow(T,Supplier<X>) (cf. Optional::orElseThrow)
>>>> - T requireNonNull(T,String) (shorthand for common use of 
>>>> requireNonNullElseThrow)
>>>
>>> Note that there is already a new method in JDK 8 not listed above:
>>> requireNonNull(T, Supplier<String>)
>>> As such, I'm not convinced that requireNonNullElseThrow will pull 
>>> its weight.
>>>
>>> I can see the benefits of this consistency of naming. (FWIW, I think
>>> the "require" prefix was a mistake, but that ship has sailed). If this
>>> naming is chosen, I'd like to see all the methods next to one another
>>> in the source file, which involves moving the method added in JDK 8.
>>>
>>> Stephen
>