RFR 9: 8138963 : java.lang.Objects new method to default to non-null
Roger.Riggs at Oracle.com
Fri Oct 9 15:46:09 UTC 2015
The primary purpose of the existing 'requireNonNull' methods is to check
and throw an exception. It is used for explicit testing and producing a
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
because it is more readable and usable.
- 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
Except for throwing some exception other than NPE, which is included in
- 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)
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
>> 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
>>> 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.
More information about the core-libs-dev