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

[Daniel Fuchs]

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