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

Paul Benedict pbenedict at apache.org
Tue Jan 25 20:33:13 UTC 2011


The other good benefit from this rename is that "requireNonNull" is much
more expressive when used as a static import.

On Tue, Jan 25, 2011 at 2:24 PM, Brian Goetz <brian.goetz at oracle.com> wrote:

> There is a webrev for CR 7012540 (java.util.Objects.nonNull() incorrectly
> named) at:
>
>    http://cr.openjdk.java.net/~briangoetz/7012540/webrev/<http://cr.openjdk.java.net/%7Ebriangoetz/7012540/webrev/>
>
> Code review would be appreciated.
>
> Text of CR:
>
> The class java.util.Objects is new for JDK 7.  Its mission is to provide
> "null-safe or null-tolerant versions of common operations on objects."
>
> The methods nonNull(x) have the behavior of throwing NPE if their argument
> is null, and returning their argument if non-null.  It is very common in
> Java source bases for a method named nonNull(x) to have the behavior of
> coercing their argument to null; that is, it is generally associated with a
> null-tolerant rather than a null-safe behavior.
>
> 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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20110125/ccdaab0e/attachment.html>


More information about the core-libs-dev mailing list