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

[Ulf Zibis]

Am 26.01.2011 00:33, schrieb Brian Goetz:
>
>> Since postconditions are labeled "ensures" in the "r/e/m" triad, this
>> method should be named "ensureNonNull".
>
> Right, there's precedent for "ensureXxx" methods to actually change the state of things to ensure 
> the postcondition, such as ensureCapacity() methods in the collection implementations.  Given that 
> a part of the motivation for this change was to leave room in the namespace for both the 
> precondition-enforcing variety (barf on null) and the postcondition-ensuring variety, aka the 
> carpet-sweeping variety ("if it is null, make it non-null") ensureNonNull sounds a lot more like 
> the the carpet-sweeping version than the version being discussed (barf on null).
+1

The funtionality is:
Check the argument for non-nullity AND return it if the condition holds, otherwise fail by throwing NPE.

"notNullChecked(x)" IMO perfectly describes this behaviour.
As a short cut, "nullChecked(x)" seems clearly enough to me.
It does not block a future ensureNonNull(x)  -> convert x to a non-null value if null.

"requireXxx" lacks the fact, that is doesn't specify the positive-case return behaviour. It's more 
suitable for a void method/operator as "assert" already does.

-Ulf