Code review: 7012540 (java.util.Objects.nonNull() incorrectly named)

[mark.reinhold at oracle.com]

> Date: Tue, 25 Jan 2011 15:24:26 -0500
> From: brian.goetz at oracle.com

> ...
> 
> These methods should be renamed to something that makes its
> checking/verification behavior clear, while preserving the convenient
> self-return property so that it can be used in cases like:
> 
>   public void fooWrapper(String s, String t) {
>       foo(checkNonNull(s), checkNonNull(t));
>   }
> 
> 
> Additional notes: After much discussion on core-libs-dev, the name
> requireNonNull() seemed the least objectionable.

I think requireNonNull(x) is confusing.

For those familiar with the "requires/ensures/modifies" triad of verbs as
a compact way of identifying the preconditions, postconditions, and side
effects of a method or procedure in a comment, a specification, or a more
formal design-by-contract framework, "requires" is just wrong.

When analyzing the invocation of foo in your example, the non-nullity of
s and t are preconditions of foo and therefore postconditions of the
check method.  Naming the check method "requireNonNull" suggests that
the check method itself has a precondition that its argument be non-null,
when in fact it's the check method's postcondition which ensures that
property.

Since postconditions are labeled "ensures" in the "r/e/m" triad, this
method should be named "ensureNonNull".

- Mark