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

Mike Duigou mike.duigou at oracle.com
Wed Jan 26 04:31:55 UTC 2011


requireNonNull() seems to be the best compromise. 

The changes look good to me.

Mike

On Jan 25 2011, at 12:24 , Brian Goetz wrote:

> There is a webrev for CR 7012540 (java.util.Objects.nonNull() incorrectly named) at:
> 
>    http://cr.openjdk.java.net/~briangoetz/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.
> 




More information about the core-libs-dev mailing list