The other good benefit from this rename is that "requireNonNull" is much more expressive when used as a static import.<br><br><div class="gmail_quote">On Tue, Jan 25, 2011 at 2:24 PM, Brian Goetz <span dir="ltr"><<a href="mailto:brian.goetz@oracle.com">brian.goetz@oracle.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">There is a webrev for CR 7012540 (java.util.Objects.nonNull() incorrectly named) at:<br>
<br>
    <a href="http://cr.openjdk.java.net/%7Ebriangoetz/7012540/webrev/" target="_blank">http://cr.openjdk.java.net/~briangoetz/7012540/webrev/</a><br>
<br>
Code review would be appreciated.<br>
<br>
Text of CR:<br>
<br>
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."<br>
<br>
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.<br>

<br>
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:<br>
<br>
  public void fooWrapper(String s, String t) {<br>
      foo(checkNonNull(s), checkNonNull(t));<br>
  }<br>
<br>
<br>
Additional notes: After much discussion on core-libs-dev, the name requireNonNull() seemed the least objectionable.<br>
<br>
</blockquote></div><br>