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

Stephen Colebourne scolebourne at joda.org
Sun Nov 1 21:46:21 UTC 2015

On 31 October 2015 at 20:29, Roger Riggs <roger.riggs at oracle.com> wrote:
> And, going back nearly to the beginning of the thread, some folks are
> familiar with
> T firstNonNull(T, T)   proposed from Guava.
> But since the exercise was turned into simplify:  (x != null) ? x :
> requireNonNull(y);
> My favorite at this point is to identify the thread as a failed attempt and
> remove it.

That would be a mistake. This is a classic simple method that the JDK
should have (given that the Elvis operator was rejected).

John's proposal is by far the best in the thread for consistency, even
if it is long (and the long-ness mistake is the fault of the previous
JDK release).

Thus, we should have

 - T requireNonNull(T) - exists already
 - T requireNonNull(T,String) - exists already
 - T requireNonNull(T,Supplier<String>) - exists already
 - T requireNonNullElse(T,T) - new

I have no great need for either of these two, although I understand
the rationale:

 - T requireNonNullElseGet(T,Supplier<T>)
 - T requireNonNullElseThrow(T,Supplier<X>)

The "require is a precondition" debate is a red herring IMO. These
methods easily make a set that check for null and "do something".
"requireNonNullElse" requires that the first argument is non-null,
just like the other three, its just that it does something softer if
it is.

Thus, I'd recommend adding "requireNonNullElse(T,T)" alone, and move on.


More information about the core-libs-dev mailing list